LINUX.ORG.RU

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

 , ,


0

2

Пара вдумчивых статей по анализу производительности в Linux.

vmstat, sar и первичная диагностика производительности

Обсуждается интерпретация параметров, входящих в вывод vmstat и их связь с реальными алгоритмами работы ядра. Рассматриваются механизмы swapping и paging, использование буферов и кэширование.

О дисках для серверных систем начального уровня

Обсуждается анализ нагрузки на файловую систему посредством iostat. Рассматривается значение и калькуляция IOPS, сравнивается выбор SAS и SATA дисков для применения в серверах.

P.S. Статьи не самые свежие, но, судя по посещаемости, они все еще будут хорошей новостью :)

>>> Весь блог



Проверено: Shaman007 ()

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

outsider ★★
()
Ответ на: комментарий от Kompilainenn

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

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

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

dch
() автор топика

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

Wormik
()
Ответ на: комментарий от Wormik

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

megabaks ★★★★
()
Ответ на: комментарий от GateKeeper

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

vm.swappiness = 0
vm.overcommit_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 1000
Это настройка I/O шедулера.

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

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

dch
() автор топика
Ответ на: комментарий от dch

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

dch
() автор топика
Ответ на: комментарий от dch

Вы же понимаете, что только что предложили решение «Избегать любых 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 ★★
()
Ответ на: комментарий от GateKeeper

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

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

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

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

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

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

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

dch
() автор топика

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

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

muon ★★★★
()
Ответ на: комментарий от GateKeeper

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Harliff ★★★★★
()

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

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

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

по теме:

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

MHz
()
Ответ на: про диски и контроллеры от MHz

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

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

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

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

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

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

dch
() автор топика
Ответ на: комментарий от dch

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

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

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

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

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

MHz
()
Ответ на: комментарий от gh0stwizard

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

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

dch
() автор топика

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

dch
() автор топика

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

Xellos ★★★★★
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от GateKeeper

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

GateKeeper ★★
()
Ответ на: комментарий от GateKeeper

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

devl547 ★★★★★
()
Ответ на: комментарий от devl547

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

GateKeeper ★★
()
Ответ на: комментарий от GateKeeper

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

devl547 ★★★★★
()
Ответ на: комментарий от devl547

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

GateKeeper ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.