У меня есть сервер, который выполняет экспорт в NFSv4 для домашних каталогов пользователей. Примерно 25 пользователей (в основном разработчики / аналитики) и около 40 серверов устанавливают экспорт в домашний каталог. Производительность оставляет желать лучшего, пользователи часто видят многосекундные задержки для простых команд (например, ls или записи небольшого текстового файла). Иногда монтирование домашнего каталога полностью зависает на минут, при этом пользователи получают ошибки «В разрешении отказано».
Оборудование представляет собой Dell R510 с двумя процессорами E5620 и 8 ГБ оперативной памяти. Имеется восемь жестких дисков 15k 2,5 ”600 ГБ (Seagate ST3600057SS), сконфигурированных в виде аппаратного RAID-6 с одним« горячим »резервом. RAID-контроллер - это Dell PERC H700 с кеш-памятью 512 МБ (Linux видит это как LSI MegaSAS 9260). ОС - CentOS 5.6, раздел домашнего каталога - ext3, с параметрами «rw, data = journal, usrquota».
У меня HW RAID настроен для представления двух виртуальных дисков в ОС: / dev / sda для ОС (загрузочный, корневой и раздел подкачки) и / dev / sdb для домашних каталогов.
Что мне кажется любопытным и подозрительным, так это то, что устройство sda часто имеет очень высокую загрузку, даже если оно содержит только ОС. Я ожидал, что этот виртуальный диск будет простаивать почти все время. Система не меняет местами согласно "бесплатно" и "vmstat". Почему на этом устройстве будет большая нагрузка?
Вот 30-секундный снимок из iostat:
Time: 09:37:28 AM
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 44.09 0.03 107.76 0.13 607.40 11.27 0.89 8.27 7.27 78.35
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 44.09 0.03 107.76 0.13 607.40 11.27 0.89 8.27 7.27 78.35
sdb 0.00 2616.53 0.67 157.88 2.80 11098.83 140.04 8.57 54.08 4.21 66.68
sdb1 0.00 2616.53 0.67 157.88 2.80 11098.83 140.04 8.57 54.08 4.21 66.68
dm-0 0.00 0.00 0.03 151.82 0.13 607.26 8.00 1.25 8.23 5.16 78.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.67 2774.84 2.80 11099.37 8.00 474.30 170.89 0.24 66.84
dm-3 0.00 0.00 0.67 2774.84 2.80 11099.37 8.00 474.30 170.89 0.24 66.84
Выглядит как iotop - идеальный инструмент для выявления подобных проблем. Но я использую CentOS 5.6, в которой недостаточно нового ядра для поддержки этой программы.
я смотрел на Как определить, какой процесс вызывает интенсивный дисковый ввод-вывод?, и помимо iotop, в одном из предложений говорилось, что нужно выполнить «echo 1> / proc / sys / vm / block_dump». Я сделал это (после направления сообщений ядра в tempfs). Примерно за 13 минут у меня было около 700 тысяч операций чтения или записи, примерно половина из kjournald, а другая половина из nfsd:
# egrep " kernel: .*(READ|WRITE)" messages | wc -l
768439
# egrep " kernel: kjournald.*(READ|WRITE)" messages | wc -l
403615
# egrep " kernel: nfsd.*(READ|WRITE)" messages | wc -l
314028
Как бы то ни было, в течение последнего часа загрузка диска с домашним каталогом постоянно превышала 90%. Мой 30-секундный iostat продолжает показывать такой вывод:
Time: 09:36:30 PM
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 6.46 0.20 11.33 0.80 71.71 12.58 0.24 20.53 14.37 16.56
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 6.46 0.20 11.33 0.80 71.71 12.58 0.24 20.53 14.37 16.56
sdb 137.29 7.00 549.92 3.80 22817.19 43.19 82.57 3.02 5.45 1.74 96.32
sdb1 137.29 7.00 549.92 3.80 22817.19 43.19 82.57 3.02 5.45 1.74 96.32
dm-0 0.00 0.00 0.20 17.76 0.80 71.04 8.00 0.38 21.21 9.22 16.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 687.47 10.80 22817.19 43.19 65.48 4.62 6.61 1.43 99.81
dm-3 0.00 0.00 687.47 10.80 22817.19 43.19 65.48 4.62 6.61 1.43 99.82
Более простой подход - обновить пакеты ОС.
CentOS 5.7 могу определенно использовать iotop. Red Hat поддерживает учет ввода-вывода на процесс в ядра 2.6.18-144, и я начал видеть, что iotop работает где-то в 2011 году через пакеты RPMForge. Red Hat сделал iotop часть стандартной ОС в 2012 году. В системе 5.7 ...
[root@Tantalalicious ~]# cat /etc/issue
CentOS release 5.7 (Final)
Kernel \r on an \m
[root@Tantalalicious ~]# uname -a
Linux Tantalalicious 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:21:01 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@Tantalalicious ~]# iotop
Total DISK READ: 25.54 M/s | Total DISK WRITE: 87.03 K/s
TID PRIO USER< DISK READ DISK WRITE SWAPIN IO COMMAND
31441 be/4 465 0.00 B/s 0.00 B/s 0.00 % 0.00 % -bash
31540 be/4 465 0.00 B/s 0.00 B/s 0.00 % 0.00 % dbc
22587 be/4 admin 0.00 B/s 0.00 B/s 0.00 % 0.00 % sh
22588 be/4 admin 0.00 B/s 0.00 B/s 0.00 % 0.00 % sh
Не думайте, что это отговорка от ответа ... Но на данный момент нет причин использовать старую ОС. EL 5.8 стабилизировал, исправил массу ошибок и дает вам доступ к необходимому инструменту профилирования (iotop). Я предполагаю, что вы уже изменили свой Лифты ввода-вывода Linux и настроил аппаратный RAID-контроллер к настоящему времени.
Ты можешь использовать lsof чтобы перечислить открытые файлы, это может помочь определить, что используется.
Изучите общую настройку производительности, например, убедитесь, что на RAID-контроллере включено кэширование с обратной записью, смонтируйте общие ресурсы ext3 и nfs с помощью noatime, настройте rsize / wsize, не монтируйте nfs с noac, если вам не нужно.