Comments 75
Судя по всему процессов стало меньше, но их размер...
Это фронтенд с 8G памяти :-)
По поводу размера процессов - это обманка. Если всё устроено, как в xcache, то там используется shared memory, а в топе она отражается у всех процессов, а на самом деле выделена она только один раз.
Автору по собственному опыту рекомендую использовать APC вместо eAccelerator'а. Он, кажется помедленнее, но зато значительно стабильнее. Я пробовал eAccelerator пару лет назад, на достаточно сложных скриптах он падал (PHP 5). Может, конечно, сейчас стало лучше...
Автору по собственному опыту рекомендую использовать APC вместо eAccelerator'а. Он, кажется помедленнее, но зато значительно стабильнее. Я пробовал eAccelerator пару лет назад, на достаточно сложных скриптах он падал (PHP 5). Может, конечно, сейчас стало лучше...
Да, shared memory. Сейчас выделено 25мегабайт на всех. Как раз:
Memory Size 26,214,336 Bytes
Memory Available 3,672,832 Bytes
Memory Allocated 22,541,504 Bytes
Cached Scripts 359
А как падал? Умирали апачи/запускались другие?
Memory Size 26,214,336 Bytes
Memory Available 3,672,832 Bytes
Memory Allocated 22,541,504 Bytes
Cached Scripts 359
А как падал? Умирали апачи/запускались другие?
> А как падал? Умирали апачи/запускались другие?
Да нет, так xcache любит иногда падать.
Я немного неправильно выразился, вернее сейчас вспомнил конкретно: он не падал, а просто какой-то мусор в аутпут кидал.
Да тогда и активность проекта была никакая. Я сейчас заглянул, там у них трак, релизы выпускаются, может действительно веселее стало - надо попробовать как-нибудь на досуге.
В пользу APC ещё и то, что его собираются в стандартную поставку включить в PHP6.
Да нет, так xcache любит иногда падать.
Я немного неправильно выразился, вернее сейчас вспомнил конкретно: он не падал, а просто какой-то мусор в аутпут кидал.
Да тогда и активность проекта была никакая. Я сейчас заглянул, там у них трак, релизы выпускаются, может действительно веселее стало - надо попробовать как-нибудь на досуге.
В пользу APC ещё и то, что его собираются в стандартную поставку включить в PHP6.
UFO just landed and posted this here
Не плохо было бы пояснить для незнающих, но интересующихся, что произошло и чему радоваться.
не вижу большой разницы в потреблении ресурсов
А вы точно включили акселератор? :)
Конечно, 2.5% это меньше, чем 3.1%, но разница настолько мизерна, что может быть случайной.
И при чём здесь "ожесточённо разнашиваемые диски"? eAccelerator экономит CPU, а не диски. Все ваши скрипты находятся в кеше независимо от того, есть акселератор или нет.
Конечно, 2.5% это меньше, чем 3.1%, но разница настолько мизерна, что может быть случайной.
И при чём здесь "ожесточённо разнашиваемые диски"? eAccelerator экономит CPU, а не диски. Все ваши скрипты находятся в кеше независимо от того, есть акселератор или нет.
исходники скриптов может в файловом кеше OS и находятся
а вот байт код без apc\eAccelerator генерится каждый раз
а вот байт код без apc\eAccelerator генерится каждый раз
Я имел в виду, что это довольно злой сервер для текущей задачи. Он и без акселератора потянул бы нагрузку в разы больше этой. Просто захотелось чтобы он меньше ворочался, раз есть такая возможность.
С дисками я, пожалуй, неверный пример привёл. По iostat не удаётся уловить разницы, нужна большая нагрузка, в разы. Да и общий объём исходного кода маловат.
С дисками я, пожалуй, неверный пример привёл. По iostat не удаётся уловить разницы, нужна большая нагрузка, в разы. Да и общий объём исходного кода маловат.
Мы успешно используем и мемкшд, и еакселератор, и AdoDB .
преимущества первого вы уже знаете (видел ошибки на сайте)
преимущества второго вот только что сказали за меня
преимущуства третьего в кешировании sql запросов, знаю что вы используете кеширование в паре с мемкешдом, но советую еще глянуть на адодб. время запроса к сожалению тоже, но сервер мускула хоть не загибается.
преимущества первого вы уже знаете (видел ошибки на сайте)
преимущества второго вот только что сказали за меня
преимущуства третьего в кешировании sql запросов, знаю что вы используете кеширование в паре с мемкешдом, но советую еще глянуть на адодб. время запроса к сожалению тоже, но сервер мускула хоть не загибается.
MySQL это наше всё :-) После переезда на новые срервера Каравана пришлось попотеть, проблем, думаю, мало кто не заметил. Всё вдруг взбударажилось и встало ребром.
До конца не помогло подключение новых тредов для FreeBSD 6.2 и оптимизация структуры базы и запросов к ней.
Видимо, помимо прочего, просто совпали моменты переезда и то время, когда myisam (да-да, все таблицы с начала жизни проекта до недавного времени были в myisam) стал не к месту для такого проекта. Кратковременное запирание таблиц приводило к гигантской очереди, которая просто не могла рассосаться.
Спокойствие настало тогда, когда в добавок к остальному посты и комментарии были переведены в InnoDB и был выделен двухгигабайтный буфер памяти. InnoDB в отличии от myisam умеет очень хорошо распоряжаться оперативной памятью: хранить там не только закешированную информацию но и целые индексы таблиц.
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 2G
Про то, как сдесь применить AdoDB пока ничего сказать не могу: не пользовался. Пока довольствуемся стандарным кешем запросов MySQL.
До конца не помогло подключение новых тредов для FreeBSD 6.2 и оптимизация структуры базы и запросов к ней.
Видимо, помимо прочего, просто совпали моменты переезда и то время, когда myisam (да-да, все таблицы с начала жизни проекта до недавного времени были в myisam) стал не к месту для такого проекта. Кратковременное запирание таблиц приводило к гигантской очереди, которая просто не могла рассосаться.
Спокойствие настало тогда, когда в добавок к остальному посты и комментарии были переведены в InnoDB и был выделен двухгигабайтный буфер памяти. InnoDB в отличии от myisam умеет очень хорошо распоряжаться оперативной памятью: хранить там не только закешированную информацию но и целые индексы таблиц.
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 2G
Про то, как сдесь применить AdoDB пока ничего сказать не могу: не пользовался. Пока довольствуемся стандарным кешем запросов MySQL.
ХАБРА ЖИЛА НА МАЙИСАМЕ????
(широко выпучив глаза)
(широко выпучив глаза)
До 400000 запросов к бекэнду в сутки, так что от одной страницы от 3-5 до 50-70 запросов к базе.
Я не сомневаюсь, что прежние авторы проблем с производительностью myisam на тех объёмах данных и той посещаемости не испытывали. Самое досадное, что на старых серверах это работало без проблем, а всплыло жутким комшаром только после переезда, так что всем долго казалось, что у меня просто руки кривые.
За то видно, где предел myisam.
Я не сомневаюсь, что прежние авторы проблем с производительностью myisam на тех объёмах данных и той посещаемости не испытывали. Самое досадное, что на старых серверах это работало без проблем, а всплыло жутким комшаром только после переезда, так что всем долго казалось, что у меня просто руки кривые.
За то видно, где предел myisam.
какая ОС были и на какую перебрались? какая версия MySQL была и на какую перешли? есть некоторые подозрения на этот счет...
С 6.2 на 6.2. MySQL 5. Разница версии в одну десятую.
Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.
Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.
Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.
Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.
точнее одну сотую
До 400000 запросов в сутки - это как-то мало. Это получается порядка 4.6 запросов/сек к backend, это всего-то 324 req/sec к БД в пиках. У меня вот req/sec к backend на торрентовском форуме ~50, и есть еще трекер (отдельное приложение) с загрузкой порядка 350 req/sec, вместе они дают порядка 1200 req/sec к БД в среднем и ~2000 req/sec в пиках. От MyISAM отказался, разумеется, уже сто лет назад, заменив на InnoDB (в MyISAM остались только таблицы с fulltext indexes), EAccelerator тоже уже давно стоит, эффект есть, вот недавно сделал все-таки frontend на Squid, дабы вообще не было обращений к backend для статики, тоже замечательно помогает. Median service time по cache hit - 0.003 sec (это статика), по cache miss (динамика) - 0.22 sec.
На форуме?
Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?
На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.
Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?
На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.
если мне не изменяет мой склероз, myisam как раз умеет хранить индексы в памяти. в отличии от InnoDB, которая может там держать таблицы
innodb_buffer_pool_size
The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.
Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.
До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.
The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.
Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.
До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.
А можно еще больше все ускорить, если отказаться от apache в пользу nginx + php as fastcgi + php-fpm
Nginx берёт на себя статику и делает это, как все знают, очень хорошо. Про наш довольно лёгкий апач, который ничего кроме php-скриптов не крутит, против fastcgi я бы не стал сейчас спорить, да и это пока не актуально.
Смотря для чего используете apache. Если только для php, то как я уже сказал выше, это лишнее.
Игорь Сысоев предупреждал, что связка nginx + php(fastcgi) может быть не стабильна. хотя многие проекты вполне хорошо себя чувствуют на этой связке - специально интересовался этим вопросом совсем не давно.
На практике она достаточно стабильна чтобы советовать ее другим. За плечами у меня три года ее использования и все проблемы которые были найдены - сейчас решены. И в nginx и в php. Обязательно берите последние версии вышеназванных продуктов.
Пока к fastcgi меня жизнь не привела.
Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:
* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.
У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.
* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests
Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:
* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.
У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.
* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests
не разу не получали вот такую картинку?
у меня на довольное крупном проекте с 350k+ хитов в сутки всё это крутится на apache 2.2+ php в связке с fc_gid (китайский fastcgi), насколько я помню в котором обошли проблему, ради которой был придуман php-fpm. Или php-fpm мне тоже может помочь? php 5.4.6
По поводу nginx - можно ли совмещать фронтенд с nginx и бэкенд с apache+php на одной машине? Как раз таки для оптимального использования памяти в случаях с подгрузкой статики.
Насчёт eAccelerator и APC - хочу, но боюсь. Раз в год ставил и apc, и mmturk (в то время он так назывался) - потом ломал голову почему падает полностью процесс апача. Вот и насколько опасно ставить это сейчас в продакшене.
По поводу nginx - можно ли совмещать фронтенд с nginx и бэкенд с apache+php на одной машине? Как раз таки для оптимального использования памяти в случаях с подгрузкой статики.
Насчёт eAccelerator и APC - хочу, но боюсь. Раз в год ставил и apc, и mmturk (в то время он так назывался) - потом ломал голову почему падает полностью процесс апача. Вот и насколько опасно ставить это сейчас в продакшене.
Ну вот, тесты показали что eAccelerator полностью делает неработоспособной вплоть до связку apache + php (cgi) + fcgid.
Во-первых, советую обстоятельно исследовать возможность отказаться от apache совсем: если у вас уже на машине есть nginx + php as fastcgi - они умеют работать напрямую, без apache. Это сэкономит память и в вашем случае немного убыстрит сайт.
Что это за странный php 5.4.6 ?
Падающие акселераторы несите в студию http://groups.google.ru/group/highload-p… , вместе с бэктрейсами, попробуем разобраться что к чему.
Что это за странный php 5.4.6 ?
Падающие акселераторы несите в студию http://groups.google.ru/group/highload-p… , вместе с бэктрейсами, попробуем разобраться что к чему.
nginx пока нет, переделывать несколько проектов, завязанных на .htaccess довольно сложно ( nginx не поддерживает ведь .htaccess от апач?).
Сорри, php 5.2.5 :)
php-fpm не использую, и пока так и не понял чем он лучше в плане скорости китайского fcgid.so + php-cgi + suexec.
А у eAccelerator судя по всему именно несовместимость с php-cgi, поддерживает только php-fastcgi, но fastcgi.coremail.cn не поддерживает php-fastcgi.
APC то хоть сможет работать в связке с fcgid ?
p.s. самое интересное что в логах ничего не пишется, вообще ничего, и только php-cgi выдаёт EACCELERATOR: Warning: "-" is cached but it's mtime is in the future. - как видим, ему попадает какой-то "-" вместо имени файла.
Сорри, php 5.2.5 :)
php-fpm не использую, и пока так и не понял чем он лучше в плане скорости китайского fcgid.so + php-cgi + suexec.
А у eAccelerator судя по всему именно несовместимость с php-cgi, поддерживает только php-fastcgi, но fastcgi.coremail.cn не поддерживает php-fastcgi.
APC то хоть сможет работать в связке с fcgid ?
p.s. самое интересное что в логах ничего не пишется, вообще ничего, и только php-cgi выдаёт EACCELERATOR: Warning: "-" is cached but it's mtime is in the future. - как видим, ему попадает какой-то "-" вместо имени файла.
http://groups.google.ru/group/highload-php-ru/browse_thread/thread/a9a6bd475b121a9b - судя по всему у товарища та же самая проблема, с неработающим php-cgi в связке в eAccelerator, в отличие от меня у него php_fpm. Официально на сайте eAccelerator сказано что оно и не может работать с php-cgi..
Совмещать на одном сервере front и back можно, и для многих (не слишком больших) проектов как раз очень эффективно.
у вас до сих пор не было акселератора? :)
Я долго думал, что может значить этот пост, и наконец понял: он значит, что у хабра все хорошо! :)
Полезна не так сама статья, как комментарии к ней. Читайте комменты от начала до конца ;)
Как подружть APC/Eacc/xdebug c http://fastcgi.coremail.cn/ под Apache ?
APC создаёт число копий кэша равное числу дочерних процессов Fastcgi, соответственно обновляя страницу apc.php видно каждый раз разный uptime и разное число хитов. Точно также дублируются и пользовательские данные.
APC создаёт число копий кэша равное числу дочерних процессов Fastcgi, соответственно обновляя страницу apc.php видно каждый раз разный uptime и разное число хитов. Точно также дублируются и пользовательские данные.
Sign up to leave a comment.
Пример использования eAccelerator для нагруженного php-проекта