1 |
Glad you have a root cause/solution. |
2 |
|
3 |
On Sat, Jan 8, 2011 at 10:49 AM, Simon <turner25@×××××.com> wrote: |
4 |
<SNIP> |
5 |
> The virtual HD is physically on a raid (unknown config). Mark, the sector |
6 |
> size issue you mention, does it have to do with aligning real HD sectors |
7 |
> with filesystem sectors (so that stuff like read-ahead will get |
8 |
> no-more-no-less than what the kernel wants)? I've read about this kind of |
9 |
> setup when I was interested in RAID long ago... Now that I know my hd is |
10 |
> actually on a raid, maybe i could benefit some I/O performance improvements |
11 |
> by tuning this a bit! |
12 |
> |
13 |
|
14 |
As it's RAID underneath it's likely set up correctly. The issue I had |
15 |
in mind was the disk being a 4K/sector disk but the person who built |
16 |
the partition not knowing to align the partition to a 4K boundary. |
17 |
That can cause a _huge_ slowdown. |
18 |
|
19 |
I doubt that's the case here. As this is a hosting service they likely |
20 |
know what they are doing in that area, and if it wasn't done correctly |
21 |
you would have noticed it before I think. |
22 |
|
23 |
> Anyway, I was told by the support team that another user on the same |
24 |
> physical machine (remember it's a xen VPS) was doing I/O intensive stuff |
25 |
> which could have "I/O starved" my system. I don't understand how starving |
26 |
> or even doing some kind of DoS attack could lead to a complete freeze on the |
27 |
> console, but eh... |
28 |
|
29 |
Makes sense actually. The other guy took all the disk I/O leaving you |
30 |
with none. If you can't get to the disk then you cannot read ebuilds |
31 |
or write compiled code, or at least not fast. |
32 |
|
33 |
> They offered to migrate my system to another physical |
34 |
> machine, and after that... I was able to perform a complete 'emerge -e |
35 |
> system' in one shot without a scratch, I even did it with --jobs=2 and |
36 |
> MAKEOPTS="-j4". After that, I started a complete "emerge --keep-going |
37 |
> --jobs=2 world" with MAKEOPTS="-j8"... (i got 4 cores: dual xeon 2Ghz) |
38 |
> |
39 |
|
40 |
So now you're in good shape...until some user on the new system starts |
41 |
hogging all the disk I/O and holds you up again. |
42 |
|
43 |
> This last emerge is still going on as I write this and is emerging pkg 522 |
44 |
> of 620 !! And there were no build errors so far... |
45 |
> |
46 |
> It's emerging glibc at the moment, so once the big emerge is finished, I'll |
47 |
> probably recompile all pkgs that depend on glibc. I believe glibc was |
48 |
> actually updated during my very initial update on monday and I haven't come |
49 |
> to do that... but I guess everything will go smoothly from here. |
50 |
> |
51 |
> Thanks again for all your help guys! |
52 |
> Simon |
53 |
|
54 |
Good that you got to the root of the problem. |
55 |
|
56 |
Good luck, |
57 |
Mark |