Linux & MySQL, тормоза при интенсивном IO

[SokolovS]

Помогиите диагностировать проблему. Есть CentOS 5.3 ядро 2.6.18-128.7.1, на нем стоит MySQL 5.1. При обычном обмене даными все прекрасно работает, но стоит только запустить операцию с интенсивным дисковым IO, как на чтение так и на запись, запросы в MySQL сразу виснут и выполняются очень долго. Если прервать эту операцию, то все накопившиеся запросы в момент выполняются. Операцией может быт как длительный INSERT большого кол-ва строк в MySQL, так и обычное копирование большого файла на диск или чтение с диска на высокой скорости.

На машине стоит RAID контроллер Adaptec 3405 в RAID-1. Такую же ситуацию наблюдал и на софтовом рейде.

Планировщик для раздела с RAID поставил noop, т.к. контроллер все равно переупорядочивает запросы.

 

Если кто сталкивался с таким поведением, как решили?

Я читал в старых списах рассылки про аналогичное поведение, якобы это связано с libata, но решения так нико и не предложил.

Edited September 21, 2009 by SokolovS

[DemYaN]

дык может сами запросы в MySQL требовательны к IO и просто не хватает ресурсов, когда параллельно запущена еще одна тяжелая io-операция?

[SokolovS]

Нет, запросы могут висет ьсамые простейшие, типа выборки по первичному ключу.

Вот интересная темка http://lkml.org/lkml/2008/12/25/26

Типа при загрузке с параметрами ядра "nosmp ide=nodma libata.dma=0" работает нормально, но какая конкретно опция влияет еще не определились.

[nuclearcat]

nosmp сразу отключает блокировки, это уже огромная разница для некоторых системных операций

 

mpstat

iostat

vmstat

и искать...

плюс зависит от типа БД - MyISAM например блокирует при запросах потаблично, с конкурентыми "длинными" запросами у него совсем туго, этот момент тоже важно не упустить

 

тюнинг сервера с нагруженной БД это отдельная песня

у меня много знакомых на этом бабло лабают :-)

[vitalyb]

SokolovS

Контроллер с батарейкой и кеш на запись включен?

[nuclearcat]

Кеш на контроллере + linux с его ср%ными barriers и некоторыми командами для принудительной записи напрямую - что мертвому припарка...

Учитывая что некоторые разработчики опенсурса иногда мягко говоря гонят - это может свести все преимущества на нет, пока не поотключаешь их излишнее рвение к data integrity.

[vitalyb]

nuclearcat

По поводу сабжевого Адаптека не скажу, но у 3ware, например, FUA отключается (почти уверен у других тоже есть соответствующие режимы). ext3 можно подмонтировать без барьеров, а lvm вообще до недавнего времени барьеры не умел. Кеш на запись в ряде случаев меняет ситуацию очень кардинально.

 

зы. data integrity довольна нужная штука :) ее обычно и преследуют ставя железный контроллер с ббу.

 

Edited September 21, 2009 by vitalyb

[DemYaN]

Еще желательно промониторить стаус-переменные MySQL через SHOW GLOBAL STATUS '%Handler_%'; (лучше загнать в rrd для наглядности), как они выглядят до и после навешивания дополнительной нагрузки.

Edited September 21, 2009 by DemYaN

[SokolovS]

плюс зависит от типа БД - MyISAM например блокирует при запросах потаблично, с конкурентыми "длинными" запросами у него совсем туго, этот момент тоже важно не упустить

Ситуация с точностью до наоборот, все запросы к базам котоыре в InnoDB висят, все MyISAM базы работают.

[SokolovS]

SokolovS

Контроллер с батарейкой и кеш на запись включен?

Да, все так, батарея и кэш на запись. Скорость записи очень высокая, но это не мешает замирать мускулю, да в прочем и не только ему, любая файловая операция при высоком IO тормозит.

Вот например так:

dd if=/dev/zero of=/var/lib/mysql/testfile bs=1M count=10000
cp /var/lib/mysql/testfile2 /home/user/testfile2

 

Пишется все со скоростью 80-90 Мб/c, а читается со скоростью 400-500 Кб/c. /var/lib и /home/user это разные разделы.

Операции выполняю параллельно в разных screen,ах

Edited September 22, 2009 by SokolovS

[SokolovS]

Подскажите тогда вот такую вещь:

# modinfo libata
filename:       /lib/modules/2.6.18-128.7.1.el5.centos.plusPAE/kernel/drivers/ata/libata.ko
version:        3.00
license:        GPL
description:    Library module for ATA devices
author:         Jeff Garzik
srcversion:     89C6026C8AD76242FDBD45D
depends:        scsi_mod
vermagic:       2.6.18-128.7.1.el5.centos.plusPAE SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1
parm:           acpi_gtf_filter:filter mask for ACPI _GTF commands, set to filter out (0x1=set xfermode, 0x2=lock/freeze lock) (int)
parm:           force:Force ATA configurations including cable type, link speed and transfer mode (see Documentation/kernel-parameters.txt for details) (string)
parm:           atapi_enabled:Enable discovery of ATAPI devices (0=off, 1=on) (int)
parm:           atapi_dmadir:Enable ATAPI DMADIR bridge support (0=off, 1=on) (int)
parm:           atapi_passthru16:Enable ATA_16 passthru for ATAPI devices; on by default (0=off, 1=on) (int)
parm:           fua:FUA support (0=off, 1=on) (int)
parm:           ignore_hpa:Ignore HPA limit (0=keep BIOS limits, 1=ignore limits, using full disk) (int)
parm:           dma:DMA enable/disable (0x1==ATA, 0x2==ATAPI, 0x4==CF) (int)
parm:           ata_probe_timeout:Set ATA probing timeout (seconds) (int)
parm:           noacpi:Disables the use of ACPI in probe/suspend/resume when set (int)
parm:           allow_tpm:Permit the use of TPM commands (int)
module_sig:     883f3504a92b0fda2f95bcb392df12c112321d09e3a20a7203a8422e8771ca452c25aea73e990956
90a0baf84160cb4b22b988f9d1d9011b162a77be2b1

По рекомендациям пробовал в опции загрузки ядра ставить libata.dma=0, но ядро ругается чо опция неизвестная, хотя по выводу выше видно что она присутствует. Так же нашел информацию что при libata.dma=0 работает старый режим работы с ATA/IDE девайсами который был еще до libata.

Вопрос как установить опцию в 0, пробовал и через modprobe.conf так

options libata dma=0

не поулчается :(

[SokolovS]

Вопрос решил, нужно было после редактирования modprobe.conf, initrd пересобрать.

[SokolovS]

Вобщем проблема решилась только в CentOS 5.5, бэкпортировали из нового ядра. Проблема на уровне ядро + железо, баг репорт уже закрыт. Долго однако.

[photon]

Я заметил, что подавляющее большинство проблем с Linux у людей с этого форума возникает при использовании RHEL/CentOS. И обычно из-за того, что там старые ядра, в которые еще не бекпортированы какие-то фичи. В чем смысл использования именно этих дистрибутивов?

[SokolovS]

Стабильность прежде всего. Пробовали работать на ванильных ядрах, не вариант, особенно для критических задач. Ядра от красношляпых очень стабильные, неожиданностей от них очень мало, новые фичи как только стабилизируются, их бэкпортируют.

 

Вероятность нарваться на багу на порядок меньше и потом бага которую я описывал длилась с 2.6.17 и до 2.6.32, т.е. пофиксили не так давно. Использование другого дистрибутива ничего бы не решило.

Edited May 30, 2010 by SokolovS

[mr.Scamp]

Ядро 2.6.32-bpo.4-amd64 из дебиановских бэкпортов.

Та же проблема - тормоза при интенсивном дисковом I/O, основная нагрузка - база Innodb.

Если начать параллельно запустить ещё что-то, занимающее диск, например пересборку ядра - получаем заметные фризы.

Выключать DMA? как-то не логично.

P.S. M/B Asus P5QL-CM, 2x WD5001AALS, lvm2 софтрейд 0, в биосе включен режим AHCI, io scheduler cfq

[    1.456019] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.456913] ata3.00: ATA-8: WDC WD5001AALS-00L3B2, 01.03B01, max UDMA/133
[    1.456955] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    1.457955] ata3.00: configured for UDMA/133

Edited May 30, 2010 by mr.Scamp

[AlKov]

Стабильность прежде всего. Пробовали работать на ванильных ядрах, не вариант, особенно для критических задач. Ядра от красношляпых очень стабильные, неожиданностей от них очень мало, новые фичи как только стабилизируются, их бэкпортируют.

 

Вероятность нарваться на багу на порядок меньше и потом бага которую я описывал длилась с 2.6.17 и до 2.6.32, т.е. пофиксили не так давно. Использование другого дистрибутива ничего бы не решило.

Не понял... Если речь идет о CentOS 5.5, то каким боком здесь ядро 2.6.32?? У 5-го вроде так и осталось ядро 2.6.18 (2.6.18-194.3.1.el5xen). Или речь не о конкретно CentOS?

Сам сейчас на пороге выбора дистриба для бордера, остановился именно на CentOS 5.5. Есть некоторые сомнения в правильности выбора, сомнения именно по ядру, т.к. практически большинство "моих" задач будет решать именно оно.. За развитием проекта CentOS практически не наблюдаю, поэтому возможно и такие вопросы.

В данном случае предстоит замена бордера на Fedora 6, там есть проблемы с многопортовыми PCI-X сетевыми картами (INTEL) и VLAN на них. Интересно, что по этому поводу известно в CentOS?

[SokolovS]

Ядро 2.6.32-bpo.4-amd64 из дебиановских бэкпортов.

Та же проблема - тормоза при интенсивном дисковом I/O, основная нагрузка - база Innodb.

Если начать параллельно запустить ещё что-то, занимающее диск, например пересборку ядра - получаем заметные фризы.

Выключать DMA? как-то не логично.

P.S. M/B Asus P5QL-CM, 2x WD5001AALS, lvm2 софтрейд 0, в биосе включен режим AHCI, io scheduler cfq

[    1.456019] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.456913] ata3.00: ATA-8: WDC WD5001AALS-00L3B2, 01.03B01, max UDMA/133
[    1.456955] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    1.457955] ata3.00: configured for UDMA/133

Проблема чаще всего на десктопных мамках на чипах от AMD/nForce и VIA. Сразу скажу, что ковыряние в настройках ничего не меняет. В 2.6.32 заметно улучшили отзывчивать при интенсивном IO, но до конца она похоже не решена. В CentOS 5.5 у меня работает все отлично, до этого были симптомы 1 в 1, например синхронизация DRBD вешала все нити MySQL намертво, они тупо копились, но запросы не исполнялись. Причем у меня стоит Adaptec 3805 и это ничего не решает тоже :) После обновления синхронизация идет на скорости 20 Мб в сек, при этом отзывчивость MySQL не страдает вобще.

 

Из того что заметил на nForce после обновления до 5.5, это то что libata подгружает только драйвер:

libata                157445  1 sata_nv

 

Хотя раньше в списке присутсвовал и pata_amd.

Все дело ИМХО как раз в libata :(

Edited May 30, 2010 by SokolovS

[SokolovS]

Не понял... Если речь идет о CentOS 5.5, то каким боком здесь ядро 2.6.32?? У 5-го вроде так и осталось ядро 2.6.18 (2.6.18-194.3.1.el5xen). Или речь не о конкретно CentOS?

Дело в том что ядро поддерживается и все изменения и исправленные баги бэкпортируются в 2.6.18, если скачаете рпм с исходниками и посмотрите что внутри, то офигеете от кол-ва патчей. Драйвера кстати обязательно бэкпортируют.

 

Сам сейчас на пороге выбора дистриба для бордера, остановился именно на CentOS 5.5. Есть некоторые сомнения в правильности выбора, сомнения именно по ядру, т.к. практически большинство "моих" задач будет решать именно оно.. За развитием проекта CentOS практически не наблюдаю, поэтому возможно и такие вопросы.

В данном случае предстоит замена бордера на Fedora 6, там есть проблемы с многопортовыми PCI-X сетевыми картами (INTEL) и VLAN на них. Интересно, что по этому поводу известно в CentOS?

Я бы не сомневался, особенно при переходе с федоры :) У вас VLAN средствами модуля 8021q или средствами сетевушки?

 

[SokolovS]

Хочется еще отметить что в репозитарии CentALT много пакетов для сетевых задач. Например есть ipt_netflow, kmod-netflow для различных вариаций, включая promisc режим. Еще хороший репозитарий Elrepo.

[AlKov]

У вас VLAN средствами модуля 8021q или средствами сетевушки?

По ядру все понятно, я вообще-то это предполагал, но сомневался.. :)

VLAN на Федоре модулем 8021q, кстати, посмотрел ядро Centos 5.5 (только-что установил на новый сервер) и обнаружил, что и там VLAN модулем. В принципе, пересобрать не проблема.

А вот как организовать VLAN средствами сетевой карты? Честно говоря, первый раз слышу. Поделитесь инфой, пожалуйста.

Сетевые на новом сервере вполне себе "крутые"

01:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
01:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

две первые - онбоард, вторая пара - двухпортовая на PCI-ex.

Очень бы хотелось заюзать их по-полной.

P.S. Также очень бы хотелось увидеть тюнинг непосредственно ядра(что включить/выключить) и sysctl в свете поставленной задачи (бордер: роутинг, NAT(порядка 1000 IP), фаервол(только подсети), при трафике около 200Mbit/s и порядка 40Kpps).

 

P.P.S. Хм.. Оказывается не все так гладко в CentOS королевстве... При попытке компиляции редактированного (родного) ядра ("make all"), получаем "мат" такого вида:

 make all
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
make[1]: *** Нет правила для сборки цели `init/main.o', требуемой для `init/built-in.o'.  Останов.
make: *** [init] Ошибка 2

Что это? "Кривые передние лапы", или "прикол" от CentOS ?? - в смысле - табУ - "ядро не лапать!!!" ???

 

Edited May 30, 2010 by AlKov

[SokolovS]

Для сетевых обязательно собрать родной igb драйвер, желательно RPM, обновляться проще будет. spec файлы интеловцы в архивы пихают, так что проблем никаких. У меня такие тоже стоят, параметры загрузки драйвера не тюнил, хотя в манах все подробнейше расписано.

 

При поднятии выполняю такой скрипт:

#!/bin/sh

# Отклчаю offload, иначе htb нормально не режет
/sbin/ethtool -K $DEVICE tso off tx off sg off

# Изменяю буферы, по дефолту 256
/sbin/ethtool -G $DEVICE rx 2048
/sbin/ethtool -G $DEVICE tx 2048

# Увеличиваю очередь, по дефолту 1000
# Должно совпадать с:
# net.core.netdev_max_backlog = 3000
# net.ipv4.tcp_max_syn_backlog = 3000
/sbin/ifconfig $DEVICE txqueuelen 3000

 

Тюнинг TCP думаю лучше настраивать под себя, есть смысл смотреть на:

net.ipv4.tcp_timestamps
net.ipv4.tcp_window_scaling
net.ipv4.tcp_sack
net.ipv4.tcp_congestion_control

 

Ядро лапать можно, но по мануалу RHEL, пересобирал нормально. Только вот зачем, особого прироста производительности не почувствуете :)

[SokolovS]

А вот как организовать VLAN средствами сетевой карты? Честно говоря, первый раз слышу. Поделитесь инфой, пожалуйста.

http://download.intel.com/design/network/ProdBrf/320025.pdf

Смотрите колонку фич. Фича есть, но сам ни разу не настраивал.

[mr.Scamp]

Ядро 2.6.32-bpo.4-amd64 из дебиановских бэкпортов.

Та же проблема - тормоза при интенсивном дисковом I/O, основная нагрузка - база Innodb.

Если начать параллельно запустить ещё что-то, занимающее диск, например пересборку ядра - получаем заметные фризы.

Выключать DMA? как-то не логично.

Проблема чаще всего на десктопных мамках на чипах от AMD/nForce и VIA. Сразу скажу, что ковыряние в настройках ничего не меняет. В 2.6.32 заметно улучшили отзывчивать при интенсивном IO, но до конца она похоже не решена. В CentOS 5.5 у меня работает все отлично, до этого были симптомы 1 в 1, например синхронизация DRBD вешала все нити MySQL намертво, они тупо копились, но запросы не исполнялись. Причем у меня стоит Adaptec 3805 и это ничего не решает тоже :) После обновления синхронизация идет на скорости 20 Мб в сек, при этом отзывчивость MySQL не страдает вобще.

Хм, у меня

00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

Попробую сломать libata, по результатам отпишусь.

[AlKov]

Для сетевых обязательно собрать родной igb драйвер, желательно RPM, обновляться проще будет. spec файлы интеловцы в архивы пихают, так что проблем никаких. У меня такие тоже стоят, параметры загрузки драйвера не тюнил, хотя в манах все подробнейше расписано.

Это каким образом делается??

Ядро лапать можно, но по мануалу RHEL, пересобирал нормально. Только вот зачем, особого прироста производительности не почувствуете :)

Зачем? Ну хотя бы для того, чтобы VLAN не модулем был, да и еще кое-какие опции включить не модулями, или отключить явно ненужные (wifi etc..)

А вот сборка так и не катит.. Даже не "правленного" ядра..

[root@border 2.6.18-194.el5-x86_64]# make bzImage modules
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTLD  scripts/genksyms/genksyms
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/pnmtologo
make[1]: *** Нет правила для сборки цели `init/main.o', требуемой для `init/built-in.o'.  Останов.
make: *** [init] Ошибка 2

Или я не по тому мануалу собираю?