Анализ и планирование производительности в Linux

ну так, интересно для развития

outsider (23.09.2011 10:19:43)

пеар бложика, не?

Kompilainenn (23.09.2011 23:44:47)

пеар. Но сей факт ничего не значит, если одновременно не рассматривать качество ресурса.

Блог авторский, "репутационный" - низкокачественного и бессмысленного контента там никогда не будет (ну, в меру интеллекта автора ;) SEO-шных компиляций - тем более.

Предосудительно ли обратить внимание сообщества на несколько полезных технических статей? (их там больше двух, кстати)

не предосудительно, но это зависит.

Kompilainenn (24.09.2011 9:55:30)

Лучше бы кто-нибудь объяснил, почему так тормозит убунта, и занимает так много ОЗУ федора.

патчено-перепатчено всё на свете
собрано под старое железо
бинари не стрипнутые
короче - обычный такой generic

megabaks (24.09.2011 10:39:44)

12309-то как? Разъяснен и побежден? Или опять "отключайте свап", или (OMFG!!!) "свап в RAM"?

GateKeeper (25.09.2011 22:22:41)

Попробуй вот это:

vm.swappiness = 0
vm.overcommit_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 1000

Рекомендуется по любому для серверных систем, в особенности - для XEN. Для десктопов, в общем - тоже ;)

Фактически, не дает одному процессу монопольно захватывать ввод-вывод на диск в большом объеме.

P.S. Это sysctl. И в последней строчке нужны подчеркивания вместо пробелов (сорри).

Вы же понимаете, что только что предложили решение "Избегать любых IO" == "Отключить свап", в то время как проблема в том, что любой IO в текущих ядрах ставит раком даже те процессы, которым этот IO ни в одно место не нужен? Я не знаю, в чем там дело, может, при IO (особенно, VM IO, NET IO такого геморроя, вроде как, не порождает), ядро загибается в генерируемых прерываниях, может, в чем-то еще. Я не хочу разбираться, я не разработчик. Но беда в том, что разработчики тоже не особенно заинтересованы, а проблема, по слухам и багу, тянется аж с 2.6.2х, если не раньше.

Я поясню, почему это не поможет: имеем 4 ядра (HT выключен) на сервере. Бьем его на 4 XEN DomU, Dom0 оставляем только как управлялку гипервизором и управлялку системным временем (ntpd, да). Предположим, 2 DomU занимаются обслуживанием СУБД, 2 - сильно нагружены в плане VM IO (например, обработка большого количества файлов и последующая кормежка этого всего тем двум СУБД). Сразу оговоримся, memory overcommit не практикуется.

В момент, когда Dom0 должен синхронизировать часы, просыпается ntpd и... тупо ждет, когда у ядра освободится немного времени между IO Wait, чтобы послать запрос, тупо ждет, чтобы потом выгрести из очереди ответ серверов (хорошо, если планировщик догадается вовремя отдать управление и UDP Answer timeout с т.з. ntpd не наступит), ну и т.д. Свапом не пахнет, но приложения, которым VM IO нафиг не упал, страдают от избытка этого VM IO. Аналогичная ситуация на десктопах при VM IO и попытках подвигать курсор мыши (вы же не будете утверждать, что драйвер курсора мыши, уходит в свап, и проблема только в page fault?).

Так я понимаю эту ситуацию, наблюдаемую ежедневно на штеудовских серверных платформах. И, напомню, репрезентативной выборкой не назовешь (слишком мало), но мои знакомые и друзья, сообщавшие об отсутствии подобных проблем, имели на борту либо чипсет, либо проц не от штеуда.

GateKeeper (26.09.2011 11:34:42)

Ну "отключить своп" - это слишком кардинальное описание ситуации, на мой взгяд. Скорее, "не пихать в своп, пока память не переполнится".

Конечно, это не универсально всем подходит, но для многих задач увеличение оперативки будет лучшим вложением.

Что касается описанной ситуации с XEN:

1) все так и есть.

2) настройки vm.dirty* существенно сегментируют ввод-вывод. В результате I/O операции становятся меньше по размеру и в них проще воткнуться новому процессу. (наглядно, к примеру, без этих настроек на десктопе "dd if=/dev/zero of=some-file" эффективно приводит к залипанию мыши, а с этими настройками - лишь иногда дергается).

3) это не решает проблему с кривыми потрохами ядра, но статистически снижает ее проявления на порядок, потому что race-ситуации возникают сильно реже (у меня вылеты XEN ядра 1 раз в 2 дня просто исчезли, хотя, думаю, редко, но будут происходить).

4) имеет смысл через xm sched_credit поднять приоритет у Dom0 (если еще не)

Спасибо! Пригодится.

А я уж подумал, что это очередное IBM_dw...

muon (27.09.2011 18:14:23)

>ядро загибается в генерируемых прерываниях

это корявость работы irq давно известна на некоторых многоядерных процессорах(говорят что тут замешан ACPI, честно - хз). Перевесь все проблемные прерывания на одно ядро. Да, потеряешь немного в производительности, зато отзывчивость повысится. Мне на одном железе это помогло, на другом нет...

Pinkbyte (27.09.2011 19:31:05)

> (говорят что тут замешан ACPI, честно - хз).

Кривые таблицы для линукса? Опять? Хотя это может объяснять, почему разрабы и Тролльвардс не чешутся, они-то себе анально огороженное железо не берут.

А можно ликбез по вопросу кривых таблиц ACPI, для тех кто не в теме?

Harliff (27.09.2011 23:41:38)

про диски и контроллеры

аппаратный RAID и SAS это конечно круто...,но

неужели не очевидно, что выбор оборудования определяется задачей и БЮДЖЕТОМ, выделенным на эту задачу

по теме:

вот не понятно почему роль размера буфера жесткого диска вообще не прозвучала...

>неужели не очевидно, что выбор оборудования определяется задачей и БЮДЖЕТОМ, выделенным на эту задачу

Вот тут очень хорошо видно то скрытое противоречие, ради которого и писалось про сравнение SAS vs SATA.

Дело в том, что при большом бюджете, на постановку задачи обычно вообще не смотрят (за любые прокосы с планированием-то отвечать придется). А при маленьком хочется оценить - будет ли от большего бюджета реальный эффект или, все таки, задача отдельно, а бюджет отдельно? :)

С размером буфера жесткого диска есть неясность. Дело в том, что линуксовый io scheduler сам эффективно компонует геометрически близкие запросы. В результате, роль (довольно небольшого) внутреннего буфера становится неясна - он получает уже длинные дефрагментированные цепочки. При малой нагрузке он не нужен, а при большой он будет перманентно переполнен.

Тут есть подводные камни - они начинаются, когда мнение линукса о геометрии системы не совпадает с реальностью (например для hardware raid).

Честно сказать, у меня нет реальных данных о влиянии внутреннего буфера диска на производительность под высокой нагрузкой.

буфер диска и есть самое интересное (тоже кстати не знаю насколько помогает)

но как минимум при линейной скорости 50Мб/с буфер в 64Мб обеспечит горизонт планирования в 1 секунду

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

в общем не так все просто с дисковой подсистемой...

а с hardware raid никогда не забуду как бегали люди у которых заглючил снятый с производства контроллер

Без пруфов статьи теряют свою актуальность. ИМХО, все уже расписано: http://www.linux-tutorial.info/modules.php?name=MContent&pageid=261 и далее там же.

gh0stwizard (28.09.2011 7:05:47)

Хорошая ссылка, кстати - добавил себе в закладки.

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

Очепятки. Первая статья.

> Для операционной _системе_, при наличии

> невозможность роста buffers будет _риводить_

>Очепятки. Первая статья.

Спасибо. Поправил.

Блин. Я прочёл как "анализ и планирование производства" в Linux. Думал тут будет про адские системы управления предприятием...

Xellos (28.09.2011 12:33:10)

хм, зато на другом помогло vm.dirty_expire_centisecs = 1000. Правда там IDE-винт и /home не отделен от корня, возможно проблема была в этом...

Pinkbyte (28.09.2011 13:20:37)

>или (OMFG!!!) "свап в RAM"?

а почему нет? СВАП в ОЗУ может неплохо сэкономить оперативку и поднять производительнось.

AVL2 (28.09.2011 13:58:51)

Прошу прощения за столь слоу, но как это сэкономит оперативку и чем это лучше "отключить свап совсем и не допускать свопинга, предоставив остальное OOM-killer'у"?

GateKeeper (16.10.2011 23:30:31)

>но как это сэкономит оперативку

zcache и ramzswap

devl547 (16.10.2011 23:35:47)

zcache - это, как я понял, gzip-фильтр для обычного свапа?

GateKeeper (17.10.2011 11:28:42)

нет, и там и там lzo.
zcache сжимает неиспользуемые кэш-страницы и вместо удаления оставляет их у себя.

devl547 (17.10.2011 11:37:15)

Т.е. формула такая: давайте нагрузим проц сжатием перед выдачей в IO, т.к. это один хрен быстрее, чем в нашем кривом VM ?

GateKeeper (17.10.2011 11:43:25)

Нет. Они все предназначены для одного - как можно сильнее минимизировать шанс затронуть жесткий диск. Использование проца и оперативы - фигня, доступ к харду намного более тормозной и затратный.

devl547 (17.10.2011 11:52:13)

Доступ к харду тормозной и затратный по определению только для приложений, которым в данный момент этот доступ нужен. В реальности же получается, что любой доступ к харду затратен даже для тех, кому кроме 2Kb оперативы и пары миллиардов тактов процессора ничего не требуется. И вот тут приходят пацаны с анальными гландодерами и показывают нам ноу-хау: "давайте отрежем себе яйца и заместо них новую голову вырастим!"

GateKeeper (17.10.2011 11:56:14)