17 Mar
2014
17 Mar
'14
10:16 p.m.
It's on this PC rather than on a server, but apt-get has become
incredibly slow recently. Reading the package lists is taking many
minutes - using time to see how long 'sudo apt-get update' takes reckons
it's
Fetched 115 kB in 6s (17.7 kB/s)
Reading package lists... Done
real 28m27.642s
user 0m19.944s
sys 0m7.828s
The root partition with /var/lib/dpkg is on an SSD drive, which has
80+GiB free space and is regularly 'trimmed'. There's nothing using an
enormous amount of CPU or disk access. Even large applications are quick
to start.
Any ideas as to why this is happening?
Ian
17 Mar
17 Mar
10:36 p.m.
On Mon, Mar 17, 2014 at 10:16:35PM +0000, Ian wrote:
It's on this PC rather than on a server, but
apt-get has become
incredibly slow recently. Reading the package lists is taking many
minutes - using time to see how long 'sudo apt-get update' takes reckons
it's
Fetched 115 kB in 6s (17.7 kB/s)
Reading package lists... Done
real 28m27.642s
user 0m19.944s
sys 0m7.828s
The root partition with /var/lib/dpkg is on an SSD drive, which has
80+GiB free space and is regularly 'trimmed'. There's nothing using an
enormous amount of CPU or disk access. Even large applications are quick
to start.
Any ideas as to why this is happening?
Your network seems slow, but says it took 6s... so there is still a gap to fill
for 30s. I don't know if maybe those 6s don't take into account some network
delay, like reverse DNS queries or something like that. I would make sure the
mirror is a "decent" one (i.e. maybe change it just to test to some really
used mirror) and the DNS servers you are using are working fine (can try with
opendns or google DNS servers to be sure).
If that is not it, maybe run it with perf and also see what "vmstat 1" and
top/perf top look while it's running ?
Hope it helps,
Rodrigo
11:40 p.m.
Rodrigo Campos said:
Your network seems slow, but says it took 6s... so
there is still a gap to fill
for 30s. I don't know if maybe those 6s don't take into account some network
delay, like reverse DNS queries or something like that. I would make sure the
mirror is a "decent" one (i.e. maybe change it just to test to some really
used mirror) and the DNS servers you are using are working fine (can try with
opendns or google DNS servers to be sure).
The getting of the info from the various repositories scrolls off the
screen too fast to read. Then it gets stuck at the 'reading package
lists...' phase which, AIUI, is just reading local data. Until recently,
that's gone from 0% to Done faster than I can count to ten, never mind a
hundred.
If that is not it, maybe run it with perf and also see
what "vmstat 1" and
top/perf top look while it's running ?
I don't have perf installed - this a sample top at the 'reading package
lists..' phase while getting it:
top - 23:31:42 up 3 days, 10:07, 15 users, load average: 1.13, 0.87, 1.13
Tasks: 254 total, 2 running, 252 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 1.4 sy, 0.0 ni, 53.3 id, 37.6 wa, 0.0 hi, 0.0 si,
0.0 st
KiB Mem: 16022464 total, 6679952 used, 9342512 free, 466836 buffers
KiB Swap: 16600060 total, 11056 used, 16589004 free, 1305176 cached
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 2470m 1.7g 53m S 24.5 11.2 168:01.45 firefox
20 0 238m 66m 18m R 2.7 0.4 12:54.50 plugin-containe
20 0 218m 52m 27m S 2.0 0.3 13:58.07 chromium-browse
20 0 517m 273m 213m S 1.7 1.8 164:34.82 Xorg
20 0 291m 51m 28m S 1.7 0.3 60:55.20 chromium-browse
20 0 32224 3636 2928 D 1.7 0.0 0:00.43 apt-get
20 0 947m 425m 18m S 1.3 2.7 84:25.01 java
20 0 266m 22m 13m S 1.0 0.1 15:40.20 mate-terminal
20 0 0 0 0 S 1.0 0.0 0:01.45 kworker/u8:1
20 0 0 0 0 S 1.0 0.0 0:00.46 kworker/u8:3
20 0 5388 1504 1064 S 0.7 0.0 7:14.54 top
etc...
(with PIDs and user edited out so it fits better!)
The wa figure (IO-wait : time waiting for I/O completion) is noticeably
high. But what's so special about reading these files?
Ian
18 Mar
18 Mar
3:27 a.m.
On Mon, Mar 17, 2014 at 11:40:20PM +0000, Ian wrote:
Rodrigo Campos said:
top - 23:31:42 up 3 days, 10:07, 15 users, load average: 1.13, 0.87, 1.13
Tasks: 254 total, 2 running, 252 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 1.4 sy, 0.0 ni, 53.3 id, 37.6 wa, 0.0 hi, 0.0 si,
0.0 st
KiB Mem: 16022464 total, 6679952 used, 9342512 free, 466836 buffers
KiB Swap: 16600060 total, 11056 used, 16589004 free, 1305176 cached
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 2470m 1.7g 53m S 24.5 11.2 168:01.45 firefox
20 0 238m 66m 18m R 2.7 0.4 12:54.50 plugin-containe
20 0 218m 52m 27m S 2.0 0.3 13:58.07 chromium-browse
20 0 517m 273m 213m S 1.7 1.8 164:34.82 Xorg
20 0 291m 51m 28m S 1.7 0.3 60:55.20 chromium-browse
20 0 32224 3636 2928 D 1.7 0.0 0:00.43 apt-get
20 0 947m 425m 18m S 1.3 2.7 84:25.01 java
20 0 266m 22m 13m S 1.0 0.1 15:40.20 mate-terminal
20 0 0 0 0 S 1.0 0.0 0:01.45 kworker/u8:1
20 0 0 0 0 S 1.0 0.0 0:00.46 kworker/u8:3
20 0 5388 1504 1064 S 0.7 0.0 7:14.54 top
etc...
(with PIDs and user edited out so it fits better!)
The wa figure (IO-wait : time waiting for I/O completion) is noticeably
high. But what's so special about reading these files?
Probably anything. It seems that at that point you are not using much swap
either, although running "vmstat 1" might give you a better idea (but I would
guess it isn't).
Is your partition aligned ? What layers are on the stack ? LVM ? RAID ?
4:14 p.m.
It looks like it's sorted itself out. I did have a lockup crash a few
days ago - hence the
top - 23:31:42 up 3 days, 10:07, 15 users,
'up 3 days' bit in top. It was restarted ok, but was that when the
problem started? Hmm.
So I have done a proper shutdown and restart, and it's now back to normal:
Reading package lists... Done
real 0m11.915s
user 0m1.912s
sys 0m0.320s
It will be interesting to see how long this lasts - fsck didn't find
anything wrong with the drives after either restart.
Ian
17 Mar
17 Mar
11:09 p.m.
I said:
Any ideas as to why this is happening?
I am somewhat glad to see that it's not just me :) see
<http://ubuntuforums.org/showthread.php?t=2104709>.
Although most of us with this issue are using SSD drives for the
directories in question, not everyone is.
Has anyone noticed this on a Ubuntu-based VPS?
Ian
11:13 p.m.
Hi Ian
On 17 Mar 2014, at 23:09, Ian <ian(a)lovingboth.com> wrote:
Has anyone noticed this on a Ubuntu-based VPS?
I run a production VPS with Ubuntu 12.04 that has SSD drives, but I’ve not seen this.
Cheers
B
--
Ben Chad, t: +44 (0) 1235 355 509, m: + 44 (0) 7854 424 144, s: benchbyte
BenchByte Limited is a company incorporated in England and Wales with registration number
8091832. Our registered office is at 91a Newtown Road, Newbury, RG14 7DD. We trade from 17
Stockey End, Abingdon, Oxfordshire, OX14 2NF.
18 Mar
18 Mar
8:21 a.m.
On Mon, Mar 17, 2014 at 10:16:35PM +0000, Ian wrote:
It's on this PC rather than on a server, but
apt-get has become
incredibly slow recently. Reading the package lists is taking many
minutes - using time to see how long 'sudo apt-get update' takes reckons
it's
No ideas as to /why/ but you could try
strace -ff -r -o /tmp/apty apt-get update
Then go inspect /tmp/apty.* for long delays as this should show you
which syscalls are taking a long time to respond. You may find that a
read is taking too long to respond.
--
Best regards,
Ed http://www.s5h.net/
3940
days inactive
3941
days old
7 comments
4 participants
participants (4)
-
Ben Chad -
ed -
Ian -
Rodrigo Campos