Узкое место ввода-вывода в Linux с движителями данных

У меня есть 24-ядерный компьютер с оперативной памятью 94,6 ГБ, на котором работает сервер Ubuntu 10.04. В боксе наблюдается высокий процент iowait, в отличие от другого нашего сервера (4 ядра), на котором выполняются процессы тех же типов и объемов. Обе машины подключены к файловому серверу VNX Raid, 24-ядерному компьютеру через 4 карты FC, а другие - через 2 гигабитные карты Ethernet. 4-ядерный компьютер в настоящее время превосходит 24-ядерный компьютер, имеет более высокую загрузку процессора и меньший% iowait.

За 9 дней безотказной работы, в среднем,% iowait составляет 16% и обычно превышает 30%. В большинстве случаев загрузка ЦП очень низкая, около 5% (из-за высокого iowait). Существует достаточно свободной памяти.

Одна вещь, которую я не понимаю, это то, почему все данные, кажется, проходят через устройство SDC, а не проходят напрямую через движки данных:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

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

Что я могу посмотреть, чтобы помочь диагностировать проблему? Почему все данные проходят через / dev / sdc? Это нормально?

ОБНОВИТЬ:

Сетевое подключение и емкость чтения / записи VNX исключены как узкие места. Мы можем достичь скорости 800 МБ / с с помощью 4-х сетевых карт (циклический перебор). Карты Fibre Channel еще не используются. VNX хорошо справляется с операциями ввода-вывода (RAID6, 30x2 ТБ, 7,2 кПМ дисков на пул в двух пулах (всего 60 дисков), около 60% чтения).

Не обращайте внимания на dm и sdc, они все являются внутренними дисками и не являются частью проблемы.

Мы думаем, что проблема может быть связана с монтированием nfs или TCP (у нас есть 5 монтирований на 5 разделов в VNX), но мы не знаем, что именно. Любой совет?

Прежде всего, если ваши процессоры (и, черт возьми! Это много 24) съедают данные быстрее, чем то, что может обеспечить хранение данных, тогда вы получаете iowait. Именно тогда ядро ​​приостанавливает процесс во время блокировки ввода-вывода (слишком медленное чтение или синхронная запись).
Поэтому убедитесь, что хранилище может обеспечить достаточную пропускную способность для 24 ядер.

Например, предположим, что ваше хранилище может обеспечить пропускную способность 500 МБ / с, если вы подключены через линию 2 Gigabit Ethernet (связь), сеть уже ограничит максимальную пропускную способность до 100-180 МБ / с. Если ваш процесс использует данные со скоростью 50 МБ / с и вы запускаете 4 потока на 4-ядерном компьютере: 4 x 50 МБ / с = 200 МБ / с. Если сеть может поддерживать 180 МБ / с, то у вас не будет большой задержки, и ваши процессоры будут загружены. Сеть здесь представляет собой небольшое узкое место.
Теперь, если вы масштабируете это до 24 ядер и 24 потоков, вам понадобится 1200 МБ / с, даже если вы измените проводку для обеспечения такой пропускной способности, ваша система хранения данных не обеспечивает более 500 МБ / с, это становится узким местом.

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

Как уже было сказано, iowait происходит, когда процесс выполняет чтение, а для получения данных требуется время, или когда он выполняет синхронизированную запись, а подтверждение модификации данных занимает время. Во время записи с синхронизацией процесс переходит в непрерывный режим сна, поэтому данные не будут повреждены. Существует один удобный инструмент , чтобы увидеть , какой вызов делает процесс повиснуть: latencytop. Это не единственный в своем роде, но вы можете попробовать.

Примечание: для вашей информации, dm означает устройство отображения, а не устройства перемещения данных.

Прежде всего, святой ад, это много железа! :)

К сожалению, так как ваша установка звучит очень сложно, я не думаю, что кто-то сможет сразу сказать: «Это ваша проблема!» ответьте, если они не сделали что-то с очень похожей или идентичной настройкой и не столкнулись с той же проблемой. Таким образом, хотя этот текст обозначен SU как «Ответ», вы, вероятно, должны рассматривать его как «Предложение». И я не могу поместить это в комментарии, потому что это слишком много слов. : S

Без знания того, как ваше оборудование сопоставлено с устройствами, трудно сказать, почему ввод / вывод происходит в одном месте, а не в другом. Как у вас установлены устройства? Ваши программы обращаются к sd*устройствам напрямую, или все ваши файловые системы смонтированы на dmустройствах, и все обращения к файлам происходят через них?

Другие вещи, о которых я должен спросить:

• Что это за RAID? Если вы вычисляете биты четности с помощью RAID5 или RAID6, об этом, надеюсь, позаботится аппаратное обеспечение raid-сервера ... если нет, то серверы обработки делают это ... что неоптимально и может привести к задержке ввода-вывода, если сделано в программном обеспечении.

• Вы выделили одно из основных различий между двумя серверами в своем сообщении. Один использует оптоволоконный канал, а другой использует Ethernet. Fibre Channel должен обеспечивать лучшую задержку и пропускную способность, но, возможно, это также является проблемой: если он обеспечивает большую пропускную способность, он может сделать сервер RAID очень занятым сам по себе ... и перегрузка приводит к заполнению буферов / кэшей, что увеличивает задержку, что приводит к увеличению ожидания ввода-вывода.

Это почти как если бы вы , возможно , есть проблема раздуваться буфера с дисковыми массивами - вы знаете? Аппаратные RAID-контроллеры обычно имеют большой объем встроенного кэша, не так ли? Таким образом, по мере того, как ввод / вывод на носители ставится в очередь, а кэш-память заполняется грязными страницами, в конечном итоге все становится насыщенным (если механическое хранилище не справляется с нагрузкой), и задержка пересекает крышу ... конечно вы можете производить больше нагрузки с 24 ядрами + FC, чем с 4 ядрами + GbE :) Проверьте сервер RAID и посмотрите, насколько загружены диски ... большая часть "ввода-вывода" может быть просто контрольными пакетами и т. д. Я Я не уверен, как работает FC, но если это что-то вроде TCP, то вы увидите повторные передачи, если задержки слишком велики.

Например, если вы задаете кому-то вопрос по телефону, и он не отвечает в течение нескольких секунд, вы говорите «Привет?». - сетевые протоколы (а FC - это просто сетевой протокол) делают то же самое, только в более короткие сроки. Но, конечно, это дополнительное "Привет?" это дорого в контексте работы в сети, поскольку добавляет еще больше данных в уже перегруженный канал.

В заключение, общий совет:

При отладке задержки / IO ожидания / проблемы пропускной способности всегда измеряйте . Мера везде. Измеряйте по проводам, измеряйте, что делают сами программы, измеряйте в конце обработки, измеряйте на сервере RAID и т. Д. Не просто смотрите на это с одной точки зрения - попробуйте рассмотреть каждый отдельный компонент системы, который является отвечает за обработку, чтение или запись любых данных в конвейере. Разберите одну транзакцию или одну отдельную рабочую единицу и рассмотрите точно путь, который она проходит через ваше оборудование, и измерьте на каждом отдельном компоненте, чтобы увидеть, есть ли узкие места или места, где есть чрезмерная задержка, и т. Д. Мой друг назвал это "отслаиванием" back the onion ", и с тех пор я использовал эту фразу для обозначения задачи отладки потока данных.

Небольшое дополнение. В этом случае вы можете посмотреть настройки вашего блока и планировщики ввода / вывода. Я не так хорошо знаком с Ubuntu, но есть множество регуляторов производительности хранилища для настройки. Это определенно относится к хранилищу SAN и базам данных.

• Взгляните на системный планировщик ввода / вывода . CFQ является значением по умолчанию, но noop и дедлайн являются обычным выбором для рабочих нагрузок базы данных.
• Смотрите эту ссылку для некоторых других параметров настройки, которые могут помочь.
• Вы упоминаете NFS и блокируете хранилище. Если блок, какие файловые системы используются? Отсюда ожидание ввода-вывода похоже на ситуацию блокировки записи. Включены ли барьеры записи? Перемонтировать ваши файловые системы с nobarrier. ( Подсказка для Ubuntu )

Некоторые соответствующие ссылки о сбоях сервера ...

Linux - реальная настройка аппаратного RAID-контроллера (scsi и cciss)

Спасибо всем за идеи и вклад. Проблема была связана с комбинацией неоптимальной конфигурации соединения Ethernet в сочетании с неисправным модулем ввода-вывода на самом VNX. Скорость ввода / вывода сейчас близка к ожидаемой. Интересно отметить, что тесты записи и чтения файлов dd и тесты iozone не смогли обнаружить это и могли читать и писать почти так же быстро, как и ожидалось.

Скоро я отредактирую больше информации, но сначала хочу сказать, что вы не должны позволять выводу iostat dm- * вводить вас в заблуждение. Device-mapper - это встроенное в ядро ​​промежуточное устройство, такое же, как md * (md0, md1 и т. Д.), Так что вы действительно заботитесь только о своих базовых устройствах. Все данные, передаваемые на ваши диски, проходят через dm / md, и фактические итоговые значения (байты, секунды и т. Д.) Являются точными, но утилита вводит в заблуждение.

Кроме того, это очень большой объем памяти. Забавные вещи начинают происходить так высоко (я сам запускаю 2x64 и 2x96), особенно если у вас один процесс, занимающий более половины оперативной памяти. Прочтите эту статью для получения дополнительной информации . В статье упоминается MySQL, но обратите внимание, что это не такMySQL специфичный. Каждый программный процесс влечет за собой штрафы за доступ к памяти другого физического процессора - думаю, 48 ГБ принадлежит одному процессу, 48 - другому. Процесс может принадлежать только одному процессу и для того, чтобы получить доступ к памяти других процессоров (после того, как его собственные 48 ГБ закончатся), он должен решить либо сохранить некоторые из своих 48 в свопе, либо заплатить огромную цену, чтобы добраться до и от память другого процесса. В статье предлагается запустить команду numactl, чтобы заставить программное обеспечение не менять местами и вместо этого платить штраф. Я лично вижу огромные улучшения от этого. Другими словами - проверьте, не поменяется ли часть вашего ввода / вывода! Используйте свободный -m (или аналогичный) для этого. Если у вас достаточно свободной памяти, но есть немного нетривиальный объем обмена (скажем, 10% плюс), это может быть вашей проблемой.

Если посмотреть на это с точки зрения хранения, есть ли у вас способ измерить задержку scsi? Время ожидания ОС включает в себя множество вещей вне контроля хранилища, но когда я захожу в свою коробку хранения и вижу задержку ввода-вывода в 2 мс, я знаю, что независимо от того, что сервер получает внутренне, на команды scsi отвечают быстро, и я могу исключить хранилище как переменную.