在这里的ubuntu服务器上,我尝试使用Java从压缩文件格式中解压缩300M图像文件。
我的解压缩速度是0.5Mbytes / sec,太糟糕了(以这种速度解压缩1.5TB需要34天)。
我试图找出原因,而我注意到的唯一奇怪的是,在执行解压缩过程时,updatedb.mlocate始终可以正常工作。我想关闭它,看看它是否挡住了它,但我对它的含义并不了解。
最佳
top - 05:16:52 up 1 day, 5:15, 3 users, load average: 2.00, 2.01, 1.83
Tasks: 83 total, 1 running, 82 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.8%sy, 0.0%ni, 8.4%id, 90.2%wa, 0.0%hi, 0.0%si, 0.2%st
Mem: 1737420k total, 1722680k used, 14740k free, 1241260k buffers
Swap: 917500k total, 160k used, 917340k free, 165448k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22901 davidpar 20 0 1051m 56m 4992 S 3 3.3 0:47.84 java
2221 root 20 0 32348 26m 268 D 1 1.6 27:57.86 updatedb.mlocat
25 root 20 0 0 0 0 S 0 0.0 10:10.77 kswapd0
678 root 20 0 15864 444 268 S 0 0.0 0:19.45 irqbalance
849 davidpar 20 0 26560 1676 332 S 0 0.1 17:17.49 screen
iotop
Total DISK READ: 4.07 M/s | Total DISK WRITE: 789.62 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2221 idle root 1556.98 K/s 6.36 K/s 0.00 % 99.61 % updatedb.mlocate
22902 be/4 davidpar 2.54 M/s 671.93 K/s 0.00 % 96.96 % java -cp /home/davidparks21/fruggutils/lib/FruggMapreduceJobs.~educe.UnpackImages /mnt/local/imagebinaries-r-00010 /mnt/ebs1/
547 be/3 root 0.00 B/s 87.47 K/s 0.00 % 0.30 % [jbd2/xvdf-8]
177 be/3 root 0.00 B/s 3.98 K/s 0.00 % 0.15 % [jbd2/xvda1-8]
1
这个问题已经影响我很多年了,我不明白为什么当脚本说一个空闲模式时,updatedb.mlocate会以高IO优先级运行...
—
Ferran Basora 2013年
为什么仍默认启用?多年来,每当我创建一个新系统时,它都会发生在我身上。:-/
—
Fernando Kosh
对于任何徘徊的人来说,为什么需要这个东西以及是否通过关闭它来破坏东西:unix.stackexchange.com/a/273283/126119
—
Ufos