У меня есть 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
Еще одна часть головоломки заключается в том, что задачи часто переходят в непрерывный спящий режим (вверху), также, вероятно, из-за задержки io.
На что можно посмотреть, чтобы диагностировать проблему? Почему все данные проходят через / dev / sdc? Это нормально?
ОБНОВИТЬ:
Сетевое соединение и возможность чтения / записи VNX исключены как узкие места. Мы можем достичь скорости 800 МБ / с с 4 подключенными сетевыми картами (циклический). Карты оптоволоконного канала еще не используются. VNX хорошо справляется с операциями ввода-вывода (RAID6, 30x2TB 7.2kRPM дисков на пул в двух пулах (всего 60 дисков), около 60% чтения).
Не обращайте внимания на вышесказанное о dm и sdc, все они внутренние диски и не являются частью проблемы.
Мы думаем, что проблема может заключаться в монтированиях nfs или TCP (у нас есть 5 подключений к 5 разделам на VNX), но не знаем, что именно. Любой совет?
Во-первых, если ваши процессоры (и черт побери! Это много 24) потребляют данные быстрее, чем то, что может обеспечить хранилище данных, тогда вы получите iowait. Это когда ядро приостанавливает процесс во время блокировки io (слишком медленное чтение или синхронная запись).
Поэтому убедитесь, что хранилище может обеспечить достаточную пропускную способность для 24 ядер.
Например, предположим, что ваше хранилище может обеспечить пропускную способность 500 МБ / с, если вы подключены через линию 2 Gigabit Ethernet (связь), сеть уже ограничит максимальную пропускную способность примерно до 100–180 МБ / с. Если ваш процесс потребляет данные со скоростью 50 МБ / с и вы запускаете 4 потока на своей 4-ядерной машине: 4 x 50 МБ / с = 200 МБ / с. Если сеть может поддерживать скорость 180 МБ / с, у вас не будет большой задержки, и ваши процессоры будут загружены. Сеть здесь - небольшое узкое место.
Теперь, если вы масштабируете это до 24 ядер и 24 потоков, вам потребуется 1200 МБ / с, даже если вы измените проводку, чтобы обеспечить такую пропускную способность, ваша система хранения не обеспечивает более 500 МБ / с, это становится узким местом.
Когда дело доходит до ожидания io, узкие места могут быть везде. Не только на физических уровнях, но и в программном обеспечении и в буферах пространства ядра. Это действительно зависит от моделей использования. Но поскольку узкие места в программном обеспечении выявить гораздо сложнее, обычно предпочтительнее проверить теоретическую пропускную способность оборудования перед исследованием программных стеков.
Как уже говорилось, iowait происходит, когда процесс выполняет чтение и данные требуют времени для доставки, или когда он выполняет синхронизирующую запись и подтверждение модификации данных требует своего времени. Во время синхронной записи процесс переходит в непрерывный спящий режим, чтобы данные не были повреждены. Есть один удобный инструмент, чтобы увидеть, какой вызов вызывает зависание процесса: latencytop. Это не единственный в своем роде, но вы можете попробовать.
Примечание: для вашей информации, dm означает устройство отображения, а не средства перемещения данных.
Во-первых, ад, это же много железа! :)
К сожалению, поскольку ваша установка кажется очень сложной, я не думаю, что кто-то сможет сразу сказать: «Вот ваша проблема!» ответьте, если только они не сделали что-то с очень похожей или идентичной настройкой и не столкнулись с той же проблемой. Таким образом, хотя этот текст помечен SU как «Ответ», вам, вероятно, следует рассматривать его как «Предложение». И я не могу добавить это в комментарии, потому что это слишком много слов. : S
Не зная, как ваше оборудование сопоставляется с устройствами, трудно сказать, почему ввод-вывод выполняется в одном месте, а не в другом. Как у вас смонтированы устройства? Ваши программы обращаются к sd* устройства напрямую, или все ваши файловые системы смонтированы на dm устройства и все обращения к файлам происходят через них?
Еще я хочу спросить:
Что это за RAID? Если вы вычисляете биты четности с помощью RAID5 или RAID6, мы надеемся, что об этом позаботится оборудование рейд-сервера ... если нет, серверы обработки делают это ... что неоптимально и может вызвать задержку ввода-вывода, если сделано программно.
В своем сообщении вы выделили одно из основных различий между двумя серверами. Один использует оптоволоконный канал, а другой - Ethernet. Fibre Channel должен обеспечивать лучшую задержку и пропускную способность, но, возможно, это также проблема: если он обеспечивает большую пропускную способность, это может сильно загружать сам RAID-сервер ... а перегрузка приводит к заполнению буферов / кешей, что увеличивает задержку, что вызывает более высокие ожидания ввода-вывода.
Это почти как если бы ты может у ваших дисковых массивов проблема с раздуванием буфера - вы знаете? Аппаратные RAID-контроллеры обычно имеют много встроенной кеш-памяти, не так ли? Так как ввод-вывод на носитель ставится в очередь, а кеши заполняются грязными страницами, в конечном итоге все становится насыщенным (если механическое хранилище не может справиться с нагрузкой), и задержка резко возрастает ... вы можете произвести большую нагрузку с 24 ядрами + FC, чем с 4 ядрами + GbE :) Проверьте RAID-сервер и посмотрите, насколько заняты диски ... большая часть "I / O" может быть просто контрольными пакетами и т. д. Я не уверен, как работает FC, но если это что-то вроде TCP, тогда вы увидите повторные передачи, если задержки слишком велики.
Например, если вы задаете кому-то вопрос по телефону, а он не отвечает несколько секунд, вы говорите «Привет?» - сетевые протоколы (а FC - это просто сетевой протокол) делают то же самое, только в более короткие сроки. Но, конечно, лишнее "Привет?" является дорогостоящим в контексте сети, поскольку добавляет еще больше данных в уже перегруженный канал.
В заключение общий совет:
При отладке проблем с задержкой / ожиданием ввода-вывода / пропускной способностью всегда мера. Измеряйте везде. Измеряйте на проводе, измеряйте, что делают сами программы, измеряйте в конце обработки, измеряйте на сервере RAID и т. Д. Не просто смотрите на это с одной точки зрения - попробуйте рассмотреть каждый отдельный компонент системы, который отвечает за обработку, чтение или запись любых данных в конвейере. Разберите одну транзакцию или одну отдельную рабочую единицу и точно проанализируйте путь, который она проходит через ваше оборудование, и измерьте каждый отдельный компонент, чтобы увидеть, есть ли узкие места или места с чрезмерной задержкой и т. Д. Мой друг назвал это «пилингом» верните лук ", и с тех пор я использую эту фразу для обозначения задачи отладки потока данных.
Небольшое дополнение. В этом случае вы можете захотеть взглянуть на настройку на уровне блоков и планировщики ввода-вывода. Я не так хорошо знаком с Ubuntu, но есть много ручек производительности хранилища, которые нужно настроить. Это определенно применимо в случае хранилища SAN и баз данных.
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 ГБ закончатся), он должен решить либо сохранить некоторые из них в свопе, либо заплатить огромную цену, чтобы добраться до и от память другого процесса. В статье предлагается запустить команду numactl, чтобы программа не меняла местами и вместо этого заплатила штраф. Я лично видел огромные улучшения от этого. Другими словами - проверьте, не собираются ли некоторые из ваших вводов / выводов поменяться местами! Используйте для этого бесплатный -m (или аналогичный). Если у вас много свободной памяти, но есть некоторый нетривиальный объем подкачки (скажем, 10% плюс), это вполне может быть вашей проблемой.
Если посмотреть на это с точки зрения хранилища, есть ли у вас способ измерить задержку scsi? Время ожидания OS io включает в себя множество вещей, не зависящих от хранилища, но когда я захожу в свой ящик для хранения и вижу задержку ввода-вывода на 2 мс, я знаю, что независимо от того, что сервер получает внутри, команды scsi реагируют на быстро, и я могу исключить хранение как переменную.