Производительность OpenVZ VPS, приглашаю обсудить мою статью о оптимизации производительности |
Здравствуйте, гость ( Вход | Регистрация )
Настоящие Правила Раздела являются дополннением к Общим Правилам Конференции. В случаях противоречий отдельных пунктов, действуют Правила Раздела.
Производительность OpenVZ VPS, приглашаю обсудить мою статью о оптимизации производительности |
BarsMonster |
13.04.2010, 07:28
Сообщение
#1
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
Приглашаю обсудить мою статью об оптимизации и тестировании производительности OpenVZ (в тексте статьи есть и реф и не-реф ссылки на хостера).
Краткое содержание: ulimit -s 1024. Apache2 mpm-prefork 4 процесса максимум, mod_php+APC. MySQL - конфиг на 160Мб памяти, на 16 коннектов максимум (больше и не понадобится по идее). Nginx - ничего особенного. Все это работает под OpenVZ на 0.5Гб памяти с еще небольшой кучкой дополнительных вещей занимает 330-350Мб памяти _независимо_ от нагрузки. Мои PHP сайты отдаются 600-170 запросов в секунду, PHPBB3 - 17. Статика - 3.8Кб файл - 1424 запроса в секунду, 45Кб файл - 638 запросов в секунду (это при том, что я не настроил отдачу статики nginx-ом напрямую) - тест был из Германии на сервер в Москве. Что на ваш взгляд можно подкрутить, особенно в MySQL для PHPBB(т.к. он "тормозит" сильнее всего)? Насколько это надежно, или я что-то упускаю? |
MIRhosting.com |
14.04.2010, 02:26
Сообщение
#2
|
Группа: Старые пользователи Сообщений: 2,034 Регистрация: 15.11.2004 Из: MIRhosting.com Ltd, The Netherlands Пользователь №: 811 Репутация: 235 |
Да все в целом замечательно, только к OpenVZ это не имеет ровным счетом никакого отношения. Это об оптимизации системы, ничего специфического по отношению к конкретно этой системы виртуализации не увидел.
Советы достаточно стандартные, они могут помочь, могут навредить. Администрирование - штука тонкая, все очень зависит от каждого конкретного сервера и проекта(ов) на нем. |
different |
14.04.2010, 03:23
Сообщение
#3
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Как-то сферично и в вакууме.
И причем тут VDS вообще и OpenVZ в частности? (IMG:style_emoticons/default/smile.gif) Подобное никто не мешает сделать и на сервере. |
different |
14.04.2010, 06:30
Сообщение
#4
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Цитата Что на ваш взгляд можно подкрутить, особенно в MySQL для PHPBB(т.к. он "тормозит" сильнее всего)? Обрезать лишнее (innodb, tcp\ip, лишнее логгирование, ndb, etc) и затюнить кэши. Но кэшей тоже без фанатизма, памяти не сады. Ну и повырубать не нужные плагины\модули\функции в самом движке. А вообще, обычно проще взять чуть более мощный VDS, чем страдать сверхоптимизацией. p.s. Очередной пиар *** своего хостера... Сообщение отредактировал Admin - 14.04.2010, 09:44 |
BarsMonster |
15.04.2010, 20:10
Сообщение
#5
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
Да все в целом замечательно, только к OpenVZ это не имеет ровным счетом никакого отношения. Это об оптимизации системы, ничего специфического по отношению к конкретно этой системы виртуализации не увидел. Цитата И причем тут VDS вообще и OpenVZ в частности? smile.gif Подобное никто не мешает сделать и на сервере. Поясню специфичность: Под OpenVZ все жрет больше памяти, т.к. считается вся выделенная виртуальная память, в которую включен и стек(грубо говоря). Для борьбы с этим - радикальное уменьшение кол-ва процессов апача, глобального размера стека, зарезание стека MySQL до 65кб. В случае с XEN и проч. этого не пришлось бы делать, а кол-во процессов апача можно было бы выбрать выше в 2-4 раза. На выделенном сервере все это делать можно, но это не приведет к максимальной производительности (там процессов можно иметь намного больше, а резать стек смысла практически нет вообще). Основные вопросы которые волнуют меня с этим конфигом: 1) Если ли какие-то подводные камни когда это может плохо работать? (кроме очевидного "4 инстанса PHP скрипта которые работают по 30 секунд и все пользователи курят" - это мои скрипты время выполнения в моей власти) 2) Что блин все-таки сделать с PHPBB? У кого PHPBB под VPS крутится - как вы делаете больше 20 запросов в секунду на главной странице? |
Boris A Dolgov |
15.04.2010, 20:25
Сообщение
#6
|
Гость Репутация: 431 |
2) Что блин все-таки сделать с PHPBB? У кого PHPBB под VPS крутится - как вы делаете больше 20 запросов в секунду на главной странице? кэшированием. Решает даже больше 1000 запросов в секунду на главной странице (IMG:style_emoticons/default/smile.gif) |
eSupport.org.ua |
15.04.2010, 22:46
Сообщение
#7
|
Одесский сисадмин Группа: Старые пользователи Сообщений: 5,200 Регистрация: 18.11.2004 Из: Одесса Пользователь №: 823 Репутация: 263 |
Выкидываем апач, ставим nginx и им-же кешируем
|
ComfoPlace.com |
16.04.2010, 17:08
Сообщение
#8
|
Группа: Старые пользователи Сообщений: 272 Регистрация: 23.03.2008 Пользователь №: 7,199 Репутация: 208 |
BarsMonster
Apache действительно "фтопку". Привяжите к nginx - php-fpm MySQL в параметры не вникал, но хотябы скипнуть тот-же innodb и шулуху не помешалобы (IMG:style_emoticons/default/smile.gif) Код skip-bdb skip-innodb skip-networking |
BarsMonster |
17.04.2010, 12:34
Сообщение
#9
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
BarsMonster Apache действительно "фтопку". Привяжите к nginx - php-fpm MySQL в параметры не вникал, но хотябы скипнуть тот-же innodb и шулуху не помешалобы (IMG:style_emoticons/default/smile.gif) Код skip-bdb skip-innodb skip-networking Насчет nginx<>php-fpm - не вяжется с бенчмарками http://forum.searchengines.ru/showpost.php...mp;postcount=39 , apache2/mod_php быстрее (и не понятно почему в тесте у них добавление сверху nginx так сильно просадило скорость...). Скипнул skip-bdb skip-innodb skip-networking - однако не заметил особой разницы с скорости/памяти... И innoDB базы продолжили работать, странно... Может надо на этапе компиляции обрубать это? Сообщение отредактировал BarsMonster - 17.04.2010, 12:35 |
eSupport.org.ua |
17.04.2010, 13:03
Сообщение
#10
|
Одесский сисадмин Группа: Старые пользователи Сообщений: 5,200 Регистрация: 18.11.2004 Из: Одесса Пользователь №: 823 Репутация: 263 |
mod_php быстрее
php-fpm легче |
BarsMonster |
17.04.2010, 14:53
Сообщение
#11
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
|
different |
17.04.2010, 17:25
Сообщение
#12
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Следовательно, если памяти хватает, Apache+nginx не в топку? Задача-то какая? Если задача выполнять минимум запросов в минимум времени на 1 запрос - mod_php. Если задача выполнять максимум запросов одновременно - php-fpm. Иными словами - не путайте производительность и скорость исполнения. (IMG:style_emoticons/default/wink.gif) |
BarsMonster |
17.04.2010, 17:36
Сообщение
#13
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
Задача-то какая? Если задача выполнять минимум запросов в минимум времени на 1 запрос - mod_php. Если задача выполнять максимум запросов одновременно - php-fpm. Иными словами - не путайте производительность и скорость исполнения. (IMG:style_emoticons/default/wink.gif) Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Опять же, ab не тестирует "латентность" - он долбит во много потоков, и фактически тестируется именно производительность. |
MiksIr |
17.04.2010, 19:10
Сообщение
#14
|
Группа: Старые пользователи Сообщений: 347 Регистрация: 23.09.2005 Пользователь №: 1,646 Репутация: 228 |
Если говорить про
|
different |
17.04.2010, 19:14
Сообщение
#15
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Опять же, ab не тестирует "латентность" - он долбит во много потоков, и фактически тестируется именно производительность. Э. Причем здесь потоки? Есть mod_php. На единичном запросе он быстрее, чем php-fpm (не всегда, но сейчас это не важно). Но потребляет ресурсов X. Есть php-fpm. На единичном запросе он медленнее, чем mod_php, но потребляет ресурсов X-0.5 (цифра с потолка). Соответственно, пока X*(количество_потоков)<totalresouce - mod_php будет таки быстрее. Когда X*(количество_потоков)=>totalresouce - возникнет нехватка ресурсов. Соответственно, новые запросы не будут обрабатываться\будут вставать в очередь\сервер начнет свопить и все станет грустно. Засчет этого на равном железе смогут обслуживаться 50 запросов в минуту mod_php или 100 запросов в минуту php-fpm. Следовательно, время от момента принятия запроса до его исполнения на таком сервере при числе запросов >50 будет наименьшим в варианте с php_fpm, хотя чистое время отработки PHP в этой ситуации у mod_php - меньше. (IMG:style_emoticons/default/smile.gif) Все цифры - с потолка и для демонстрации логики. Цитата Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Что вы хотите этим сказать? Помимо процессора есть и другие ресурсы, если что. Это было бы верно в идеальной ситуации, когда каждый поток использует только CPU, а сети, памяти и I\O у нас нет вообще. Пример. У нас жесткое ограничение на 4 конкурентных запроса. Пришли 4 человека. Они сидят через GPRS. Им нужно отдать 1МБ информации. Пока они ее сосут (медленно) приходит пятый. Он вынужден ждать в очереди, пока хотя-бы один из четырех отвалится и "уступит место". Соответственно, свои данные он получит гораздо позже, чем получил бы при 5 разрешенных конкурентах. Так? Так. Хотя количество физических ядер у нас не поменялось. Аналогично произойдет, если один поток пишет на диск (к примеру) или дергает медленную базу, а другим потокам это не нужно, они отдают картинки. И т.д. и т.п. Смотреть надо профиль конкретной нагрузки. Вообще, вы тестируете что-то сферическое и в вакууме, как я уже и говорил. |
BarsMonster |
17.04.2010, 19:37
Сообщение
#16
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
Пришли 4 человека. Они сидят через GPRS. Им нужно отдать 1МБ информации. Пока они ее сосут (медленно) приходит пятый. Он вынужден ждать в очереди, пока хотя-бы один из четырех отвалится и "уступит место". Этот сценарий абсолютно понятен, и потому вариант Apache на 4 потока без nginx даже не рассматривается. В любом случае есть nginx. Из-за наличия nginx апач и работает в "сферическом" состоянии - для него получение и отправка данных происходит мгновенно и без задержек, поэтому ab покажет ту же картину, что и реальность. nginx-у-то все равно, будет у него 10 быстрых клиентов, или 5000 через GPRS - нагрузка из-за постепенной отдачи будет около нулевая в любом случае. Я говорю о том, что нет нужды стремиться обрабатывать очень много запросов одновременно, и есть причины по которым 4 процесса быстрее чем 40 - меньше потери на переключение контекста и перегрузки кешей. А т.к. 4-8 апачей в память влезут всегда, это и становится оптимальным вариантом для многих случаев. Сообщение отредактировал BarsMonster - 17.04.2010, 19:40 |
eSupport.org.ua |
17.04.2010, 20:21
Сообщение
#17
|
Одесский сисадмин Группа: Старые пользователи Сообщений: 5,200 Регистрация: 18.11.2004 Из: Одесса Пользователь №: 823 Репутация: 263 |
4-е процесса не всегда будут отдавать сайты быстрее 40
|
MiksIr |
18.04.2010, 21:46
Сообщение
#18
|
Группа: Старые пользователи Сообщений: 347 Регистрация: 23.09.2005 Пользователь №: 1,646 Репутация: 228 |
Цитата Я говорю о том, что нет нужды стремиться обрабатывать очень много запросов одновременно, и есть причины по которым 4 процесса быстрее чем 40 - меньше потери на переключение контекста и перегрузки кешей. А т.к. 4-8 апачей в память влезут всегда, это и становится оптимальным вариантом для многих случаев. По моей практике - 5-6 процессов на ядро, но при этом база сидит на другой машине. Хотя, если база на той же машине, наверно не сильно что изменится - ибо когда работает база PHP сидит в ожидании. Зависит так же от того, что PHP делает. Если сложная математика - меньше, если больше база и другой IO - больше. А возвращаясь к вопросу про то, чем топить - апач и правда можно выкинуть. В конце концов даже из соображения уменьшения точек конфигурирования =) Сообщение отредактировал MiksIr - 18.04.2010, 21:48 |
BarsMonster |
19.04.2010, 09:00
Сообщение
#19
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
А возвращаясь к вопросу про то, чем топить - апач и правда можно выкинуть. В конце концов даже из соображения уменьшения точек конфигурирования =) Ну, если апач быстрее, я бы его уже не выкидывал - многим сайтам нужен .htaccess, отдельные опции PHP для каждого сайта.... Вот когда сделают nginx со встроенным php... :-) А так - точек конфигурирования для запуска PHP в FCGI больше, насколько я помню... |
MiksIr |
19.04.2010, 18:05
Сообщение
#20
|
Группа: Старые пользователи Сообщений: 347 Регистрация: 23.09.2005 Пользователь №: 1,646 Репутация: 228 |
Ну, если апач быстрее, я бы его уже не выкидывал - многим сайтам нужен .htaccess, отдельные опции PHP для каждого сайта.... Вот когда сделают nginx со встроенным php... :-) А так - точек конфигурирования для запуска PHP в FCGI больше, насколько я помню... Подождите, апач быстрее в голом виде. Но вы же сами сказали, что понимаете, что nginx перед апачем нужен. А теперь внимательно еще раз смотрите тест по своей ссылке. nginx+php-fpm быстрее чем nginx+apache/mod_php. Насчет опций пхп и htaccess, если у вас не хостинговый сайт (что было бы странно в контексте VPS), то это больше разговоров, чем проблем, тем более, что если отдавать статику через nginx - то уже про htaccess речи не идет. А кастомные флаги/php.ini в php-fpm можно выставлять. Насчет конфигурирования - как минимум каждый новый виртуальный хост придется прописывать и в nginx (что бы статику отдавать) и в апач. Сообщение отредактировал MiksIr - 19.04.2010, 18:07 |
different |
19.04.2010, 18:13
Сообщение
#21
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Ну, если апач быстрее, я бы его уже не выкидывал - многим сайтам нужен .htaccess, отдельные опции PHP для каждого сайта.... Вот когда сделают nginx со встроенным php... :-) А еще поддержку .htaccess, .htpasswd, webdav, 2-3 мультипроцессорных модели.. ой. извините. Получился еще один Апач. |
BarsMonster |
19.04.2010, 21:10
Сообщение
#22
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 193 |
Подождите, апач быстрее в голом виде. Но вы же сами сказали, что понимаете, что nginx перед апачем нужен. А теперь внимательно еще раз смотрите тест по своей ссылке. nginx+php-fpm быстрее чем nginx+apache/mod_php. Насчет опций пхп и htaccess, если у вас не хостинговый сайт (что было бы странно в контексте VPS), то это больше разговоров, чем проблем, тем более, что если отдавать статику через nginx - то уже про htaccess речи не идет. А кастомные флаги/php.ini в php-fpm можно выставлять. Насчет конфигурирования - как минимум каждый новый виртуальный хост придется прописывать и в nginx (что бы статику отдавать) и в апач. Мои тесты не подтверждают такой просадки производительности на синтетических тестах от добавления nginx - у меня она укладывается в 10-15% (в то тесте - 37%). Возможно, там буферы nginx-а стояли сильно большие, или сжатие на 9-тку или еще что... В php-fpm кастомные флаги выставлять можно насколько я помню только на целый демон, т.е. хотите 2 конфигурации - имейте 2 разных демона в памяти... В nginx делать vhost на каждый сайт не обязательно - есть вариант с единым конфигом на все (особенно если статика в более-менее тех же каталогах относительно корня сайта). Насчет хостинг/не хостинг - в любом случае производительность и удобство настройки имеет значение, особенно если писать гайд. |
Solistiks |
18.07.2010, 14:54
Сообщение
#23
|
Группа: Старые пользователи Сообщений: 1 Регистрация: 29.06.2010 Из: Россия Пользователь №: 12,149 Репутация: 184 |
Сколько ни пробовал поднять производительность с помощью этой приблуды, в fpsaх так ничего и не увидел. Да, действительно, до ее применения нагрузка идет на одно ядро, при ее применении на два, но в fps ничего не прибавлялось.
|
Seneka |
27.09.2010, 11:03
Сообщение
#24
|
Группа: Старые пользователи Сообщений: 1 Регистрация: 27.09.2010 Из: Москва Пользователь №: 12,588 Репутация: 183 |
Попробовал несколько VDS на OpenVZ - везде оверселлинг и периодические тормоза системы, даже без нагрузки. Взял VDS на XENe - пока работает нормально. Почему такая разница? (IMG:style_emoticons/default/ohmy.gif) Причем по стоимости почти одно и тоже
|
eSupport.org.ua |
27.09.2010, 12:14
Сообщение
#25
|
Одесский сисадмин Группа: Старые пользователи Сообщений: 5,200 Регистрация: 18.11.2004 Из: Одесса Пользователь №: 823 Репутация: 263 |
Разница в почти
|
Текстовая версия | Сейчас: 22.05.2024, 20:53 |