Apache httpd интеграция LDAP

Я не думаю, что Ваш диск является проблемой. ncache первого nginx использует дисковое хранилище для кэша. Так, скорость диска будет одной потенциальной причиной проблем в зависимости от того, насколько горячий/холодный Ваш набор данных, однако, я не вижу оснований, что Вы не могли служить 100mb/sec с аппаратными средствами, которые Вы упомянули - особенно при использовании nginx.

Первой вещью, которую я предположил бы, является Ваш # рабочих процессов, было низким, Ваши worker_connections были, вероятно, слишком низкими, и у Вас, вероятно, не было своего набора open_file_cache достаточно высоко. Однако ни одна из тех настроек не вызвала бы высокий IO, Ожидают, ни скачок как этот. Вы говорите обслуживание <50k изображений, и похоже, что 1/4 набора мог легко быть буферизован ОС. Nginx, конечно, не настроен оптимально.

Лак решает проблему в немного отличающемся способе использовать RAM, а не диск для его кэша.

Много зависит от Вашего набора данных, но, на основе данных Вы дали, я не вижу оснований для диска IO для пронзания как этот. Вы проверяли dmesg и журналы, чтобы видеть, встретился ли один из Ваших дисков с некоторыми ошибками IO в то время? Единственная другая вещь я могу думать, что это, возможно, вызвало тот скачок, превышала filecache nginx, который заставит это должным быть входить в режим FIFO, открывающий новые файлы.

Удостоверьтесь, что Ваша файловая система смонтирована с noatime, который должен сократить значительную сумму writeops от Вашей рабочей нагрузки.

Как пример машины, которая регулярно обрабатывает 800mb/sec:

# uptime
 11:32:27 up 11 days, 16:31,  1 user,  load average: 0.43, 0.85, 0.82

# free
             total       used       free     shared    buffers     cached
Mem:       8180796    7127000    1053796          0       1152    2397336
-/+ buffers/cache:    4728512    3452284
Swap:      8297568     237940    8059628

Quadcore Xeon:
    Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz

$ ./bw.pl xxx.xxx 2010-09-01 2010-09-30
bw: 174042.60gb

average 543mb/sec, peaks at 810mb/sec

=== START OF INFORMATION SECTION === Model Family:     Seagate Barracuda
7200.12 family Device Model:     ST3500418AS Serial Number:    6VM89L1N
Firmware Version: CC38 User Capacity: 
500,107,862,016 bytes

Linux 2.6.36-rc5 (xxxxxx)   10/04/2010  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.33    0.00    2.40    5.94    0.00   87.33

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             109.61     19020.67       337.28 19047438731  337754190

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.09    0.00    3.40   10.26    0.00   78.25

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             138.52     21199.60       490.02     106210       2455

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.74    0.00    3.25    9.01    0.00   84.00

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             125.00     21691.20       139.20     108456        696

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    3.12   14.02    0.00   78.11

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             154.69     19532.14       261.28      97856       1309

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.81    0.00    3.36    9.48    0.00   80.36

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             112.80     17635.20       309.00      88176       1545

MRTG:

http://imgur.com/KYGp6.png

Набор данных:

# du -sh ads
211.0G  ads

# ls|wc -l
679075