У меня есть специально построенный сервер Ubuntu 11.04 с 6-ти дисковым программным RAID 10 основным диском. На нем я в основном использую PostgreSQL и несколько других утилит, которые передают данные из Интернета. Я часто обнаруживаю, что после нескольких часов безотказной работы сервер начинает отставать от всех видов процессов. Например, после входа в систему может пройти 10-15 секунд, чтобы получить приглашение оболочки. Это может занять 5-10 секунд top придумать. An ls может занять секунду или две.
Когда я смотрю вверху, загрузка ЦП практически отсутствует. Сервер PostgreSQL использует изрядный объем памяти, но его недостаточно для использования в свопинге.
Я понятия не имею, что делать дальше, кроме как подозревать RAID10 (раньше у меня были только программные RAID 1).
Изменить: вывод сверху:
top - 11:56:03 up 1:46, 3 users, load average: 0.89, 0.73, 0.72
Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 93.5%id, 6.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16325596k total, 3478248k used, 12847348k free, 20880k buffers
Swap: 19534176k total, 0k used, 19534176k free, 3041992k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1747 woodsp 20 0 109m 10m 4888 S 1 0.1 0:42.70 python
357 root 20 0 0 0 0 S 0 0.0 0:00.40 jbd2/sda3-8
1 root 20 0 24324 2284 1344 S 0 0.0 0:00.84 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.24 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/0
8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
10 root 20 0 0 0 0 S 0 0.0 0:00.02 ksoftirqd/1
12 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/1
13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2
14 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/2:0
15 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2
16 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/2
17 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3
18 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/3:0
19 root 20 0 0 0 0 S 0 0.0 0:00.02 ksoftirqd/3
20 root RT 0 0 0 0 S 0 0.0 0:00.01 watchdog/3
21 root 0 -20 0 0 0 S 0 0.0 0:00.00 cpuset
22 root 0 -20 0 0 0 S 0 0.0 0:00.00 khelper
23 root 20 0 0 0 0 S 0 0.0 0:00.00 kdevtmpfs
24 root 0 -20 0 0 0 S 0 0.0 0:00.00 netns
26 root 20 0 0 0 0 S 0 0.0 0:00.00 sync_supers
df -h
rpsharp@ncp-skookum:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 1.8T 549G 1.2T 32% /
udev 7.8G 4.0K 7.8G 1% /dev
tmpfs 3.2G 492K 3.2G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 7.8G 0 7.8G 0% /run/shm
/dev/sda2 952M 128K 952M 1% /boot/efi
/dev/md0 5.5T 562G 4.7T 11% /usr/local
бесплатно -m
psharp@ncp-skookum:~$ free -m
total used free shared buffers cached
Mem: 15942 3409 12533 0 20 2983
-/+ buffers/cache: 405 15537
Swap: 19076 0 19076
хвост -50 / var / журнал / системный журнал
Jul 3 06:31:32 ncp-skookum rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="1070" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jul 3 06:39:01 ncp-skookum CRON[14211]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 06:40:01 ncp-skookum CRON[14223]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:00:01 ncp-skookum CRON[14328]: (woodsp) CMD (/home/woodsp/bin/mail_tweetupdate # email an update)
Jul 3 07:00:01 ncp-skookum CRON[14327]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:00:28 ncp-skookum sendmail[14356]: q63E0SoZ014356: from=woodsp, size=2328, class=0, nrcpts=2, msgid=<201207031400.q63E0SoZ014356@ncp-skookum.Stanford.EDU>, relay=woodsp@localhost
Jul 3 07:00:29 ncp-skookum sm-mta[14357]: q63E0Si6014357: from=<woodsp@ncp-skookum.Stanford.EDU>, size=2569, class=0, nrcpts=2, msgid=<201207031400.q63E0SoZ014356@ncp-skookum.Stanford.EDU>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Jul 3 07:00:29 ncp-skookum sendmail[14356]: q63E0SoZ014356: to=Spencer Wood <woodsp@stanford.edu>,Martin Lacayo <mlacayo@stanford.edu>, ctladdr=woodsp (1004/1005), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=62328, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (q63E0Si6014357 Message accepted for delivery)
Jul 3 07:00:29 ncp-skookum sm-mta[14359]: STARTTLS=client, relay=mx3.stanford.edu., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 3 07:00:29 ncp-skookum sm-mta[14359]: q63E0Si6014357: to=<mlacayo@stanford.edu>,<woodsp@stanford.edu>, ctladdr=<woodsp@ncp-skookum.Stanford.EDU> (1004/1005), delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=152569, relay=mx3.stanford.edu. [171.67.219.73], dsn=2.0.0, stat=Sent (Ok: queued as 8F3505802AC)
Jul 3 07:09:08 ncp-skookum CRON[14396]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 07:17:01 ncp-skookum CRON[14438]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 3 07:20:01 ncp-skookum CRON[14453]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 07:39:01 ncp-skookum CRON[14551]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 07:40:01 ncp-skookum CRON[14562]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:00:01 ncp-skookum CRON[14668]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:09:01 ncp-skookum CRON[14724]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 08:17:01 ncp-skookum CRON[14766]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 3 08:20:01 ncp-skookum CRON[14781]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Jul 3 08:39:01 ncp-skookum CRON[14881]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jul 3 08:40:01 ncp-skookum CRON[14892]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Вывод hdparm -t / dev / sd {a, b, c, d, e, f} Это выглядит подозрительно?
/dev/sda:
Timing buffered disk reads: 2 MB in 4.84 seconds = 423.39 kB/sec
/dev/sdb:
Timing buffered disk reads: 420 MB in 3.01 seconds = 139.74 MB/sec
/dev/sdc:
Timing buffered disk reads: 390 MB in 3.00 seconds = 129.87 MB/sec
/dev/sdd:
Timing buffered disk reads: 416 MB in 3.00 seconds = 138.51 MB/sec
/dev/sde:
Timing buffered disk reads: 422 MB in 3.00 seconds = 140.50 MB/sec
/dev/sdf:
Timing buffered disk reads: 416 MB in 3.01 seconds = 138.26 MB/sec
У меня есть идея. Когда вы опубликовали вывод hdparm, он говорит, что диск SDA очень медленный. Это могло быть потому, что:
а) У вас есть / и (часть) вашего RAID 10 на одном диске, или ...
б) Проблема с каким-то драйвером.
Если вы обновили ядро, попробуйте использовать значение по умолчанию, которое поставляется с Ubuntu.
Как указал @Oneiroi, вы должны попробовать iotop и в фоновом режиме запускать программы. Вы можете запустить команду ls там, где установлен RAID, отдельно; а затем запустите ls на / и на RAID. Если он замедляется, это может быть причина: а.
Попробуйте использовать grep для поиска в / var / log / dmesg, syslog и сообщениях таких слов, как hdd, kernel, raid или postgresql.
Кроме того, я бы попытался отключить sda и отключить от RAID. Затем попробуйте снова hdparm. Если работает, значит проблема в диске sda.
Другой возможный случай - проблема в PostgreSQL. Если возможно, вы можете запустить сервер без PostgreSQL и посмотреть, сохраняется ли проблема. Если проблема не исчезла, отключите все остальные службы, которые могут быть у вас. Вы также можете попробовать закрыть все, кроме PostgreSQL. Если вы можете это сделать, вы можете знать, вызвана ли проблема
а) PostgreSQL
б) Прочие услуги
в) Манипулирование большими объемами данных
г) Сама система.
В зависимости от того, что вы пробовали раньше, вы можете указать, какая у вас проблема (a, b, c или d), и получить более качественную помощь.
Кроме того, если у @SilverbackNet будет возможность, он может рассказать нам о своем сервере; Итак, теперь у нас есть то, что похоже на обоих серверах, и есть решение.
ПД: Извините за плохой английский. Редактировать и исправлять ошибки; там должно быть много.
PD2: Надеюсь, это будет полезно, но это просто набор теорий, которые, как я думал, могут помочь :)
Фактически вы используете как физический контроллер хранилища, который предоставляет ваши диски ядру Linux (независимо от того, используете ли вы его встроенные возможности RAID), так и программный RAID. Вы не можете исключить возможность того, что ваш контроллер хранилища плохо поддерживается. Используйте вывод hdparm -t / dev / sd {a, b, c, d, e, f} для диагностики проблемы (выполнение этой команды займет некоторое время).
Поскольку вы видите чрезмерно медленную работу / dev / sda, я подозреваю, что произошел сбой диска или контроллера. Дважды проверьте, хорошо ли поддерживается ваш контроллер хранилища, и постарайтесь как можно быстрее заменить / dev / sda.
Две другие возможности:
Идет слишком много журналов, или файлы журналов не очищаются должным образом. Если они стали очень большими, требуется время для их загрузки / сохранения во время обычных операций.
Проблема с сетевым подключением или SSH. У меня были аналогичные симптомы с Ubuntu 11, когда, когда я подключаюсь к машине по SSH, кажется, что соединение SSH зависает или очень медленно реагирует даже через короткий период времени. Однако прямое подключение монитора кажется таким же быстрым, как и прежде. С сервером Ubuntu 12 проблемы исчезли.
Когда я печатаю это, есть одна возможная вещь, полностью упущенная из деталей.
Возможно, что-то вызывает множество переключений контекста и / или прерываний? Это, вероятно, проявится как много system% в top, но в любом случае взгляните на vmstat 1 и смотреть in и cs столбцы. И вставьте результат тоже в свой вопрос.
Похоже, вы проверили очевидные вещи - это немного загадка.
Вы нигде не используете LVM? (Я не вижу здесь ничего похожего на устройство LVM) снимки состояния убивают производительность LVM.
Убедитесь, что ваш irqbalance работает и разумно распределяет прерывания по физический сердечники (не гиперпотоковые).
Какой планировщик io вы используете? Предполагая, что у вас нет аппаратного RAID-контроллера с большим объемом памяти, крайний срок, вероятно, является наиболее разумным вариантом, но попробуйте CFQ, если у вас в настоящее время настроен крайний срок.
Какие файловые системы и варианты монтирования? Как вы настроили диски (для ide / data что вам сообщает hdparm - проверьте настройки акустики, DMA, опережения чтения и кеширования)?