Анализ загруженного сервера lighttpd, обслуживающего NFS

Контекст:
- Сервер представляет собой виртуальную машину CentOS 5.2 x86_64 с vmxnet3 ifaces, работающую на VSphere 4.1 на сервере на базе Nehalem (который составляет половину центрального процессора и объема памяти по данным VCenter) с сетью 10 Гб. Почти нулевой ввод-вывод на виртуальном scsi-диске виртуальной машины согласно iostat.
- Читает видео из кластера Isilon, используя NFS (atime отключен)
- Обслуживает их с помощью lighttpd 1.5.0 с 20% процессором. Около 650 HTTP-соединений, включая 550 установленных, в среднем 100 Кбайт в Send-Q.

По мере того, как мы загружаем на сервер больше запросов, увеличивается время ожидания процессора и IRQ. Память не проблема.

Cpu0  :  0.0%us,  3.0%sy,  0.0%ni, 18.0%id,  0.0%wa, 32.0%hi, 47.0%si,  0.0%st
Cpu1  :  3.0%us,  4.0%sy,  0.0%ni, 55.4%id, 34.7%wa,  0.0%hi,  3.0%si,  0.0%st

4163 irq / s на интерфейсе, используемом HTTP, и 2269 irq / s на одном для NFS, согласно / proc / interrupts. Для 180 Мбит / с и 130 Мбит / с согласно iptraf соответственно.

iostat для монтирования NFS:

rBlk_nor/s   wBlk_nor/s   rBlk_dir/s   wBlk_dir/s   rBlk_svr/s   wBlk_svr/s    rops/s    wops/s
63737.87         0.00         0.00         0.00     61364.71         0.00   1098.04   1107.84

Эй, ох? Но нет setattr и тому подобного в / proc / self / mountstats:

    opts:   ro,vers=3,rsize=32768,wsize=32768,acregmin=1200,acregmax=1200,acdirmin=1200,acdirmax=1200,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys
    age:    2405948
    caps:   caps=0x1,wtmult=8192,dtsize=4096,bsize=0,namelen=255
    sec:    flavor=1,pseudoflavor=1
    events: 3496282 32148506 1 1697 3176945 2598729 37924190 0 33339443 67286271 0 0 20 0 0 0 0 3176406 0 0 0 0 0 0 0
    bytes:  31773968205376 0 0 0 31969360034250 0 7805430344 0
    RPC iostats version: 1.0  p/v: 100003/3 (nfs)
    xprt:   tcp 779 0 50 250 0 1014646219 1014646203 0 8377876491 11916594888
    per-op statistics
            NULL: 0 0 0 0 0 0 0 0
         GETATTR: 3496282 3496282 0 461510280 391583584 2165765 2594488 5332330
         SETATTR: 0 0 0 0 0 0 0 0
          LOOKUP: 2598882 2598882 0 374792176 623714816 3558569 79355750 83640121
          ACCESS: 2824036 2824036 0 384066672 338884320 1788232 2276978 4482334
        READLINK: 0 0 0 0 0 0 0 0
            READ: 1005726981 1005726982 0 144824685416 32098094238420 7454826308 4671373832 13644100410
           WRITE: 0 0 0 0 0 0 0 0
          CREATE: 0 0 0 0 0 0 0 0
           MKDIR: 0 0 0 0 0 0 0 0
         SYMLINK: 0 0 0 0 0 0 0 0
           MKNOD: 0 0 0 0 0 0 0 0
          REMOVE: 0 0 0 0 0 0 0 0
           RMDIR: 0 0 0 0 0 0 0 0
          RENAME: 0 0 0 0 0 0 0 0
            LINK: 0 0 0 0 0 0 0 0
         READDIR: 0 0 0 0 0 0 0 0
     READDIRPLUS: 13 13 0 2132 23788 60 1240 1300
          FSSTAT: 2 2 0 256 336 0 0 0
          FSINFO: 1 1 0 128 164 0 10 10
        PATHCONF: 0 0 0 0 0 0 0 0
          COMMIT: 0 0 0 0 0 0 0 0

Как определить, является ли проблема с использованием процессора iowait и irq со стороны HTTP или NFS? Или как узнать, достигает ли хост VSphere своих ограничений ввода-вывода?

nodiratime также может помочь, но я подумал, что это также указано в setattr

cpu0 имеет очень большое количество аппаратных / программных прерываний, а cpu1 имеет достаточно высокое время ожидания, равное 200 МБ / с, даже с учетом того, что ваш набор данных в основном холодный. Если это длинные видео, ваш rsize может вызывать чрезмерную фрагментацию, если mtu eth1 мал. Я почти думаю, что твой размер слишком велик. Вы можете запустить несколько тестов с другой рабочей станции, используя dd и различные параметры монтирования, чтобы увидеть, оказывает ли 32768 отрицательное влияние на вещи.

Разместите билет с Isilon, их технические ребята тоже неплохо умеют отлаживать это.