|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте.
Хотелось бы сравнить показания mysqladmin stat - Queries per second avg: тех кто считает что его сервер работает под высокой нагрузкой, что бы понять сколько способен обслуживать сервер без потери быстродействия.
Для чистоты эксперимента я думаю следовало бы писать OS, кол-во памяти на серваке, так же количество и параметры процессора. В идеале было бы неплохо storage engine, ну да бог с ним - мне бы хоть приблизительно прикинуть.
И так начну с себя.
FreeBSD 6.2
3Gb
Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
ncpu: 8
Queries per second avg: 85.720
максимум что я видел это коло 100.
Считаю сайт достаточно нагруженым.
При этой нагрузке он работает без потери быстродействия.
Неактивен
Все зависит от того, что конкретно делает Ваш сервер — тип запросов, структура
базы, и т.п. Тот же апач (у Вас же апач, и он стоит на той же машинке?) жрет кучу
ресурсов почем зря.
100 запросов в секунду — это не особо тяжелая нагрузка для сервера,тем более
на 8 ядрах. Если хотите понять, на скольких RPS реально просаживается Ваш сервер —
стрельните в него ab и посмотрите, сколько он выдержит 
Неактивен
paulus написал:
Тот же апач (у Вас же апач, и он стоит на той же машинке?) жрет кучу
ресурсов почем зря.
нет. база у меня на отдельном сервере и живет там одна.
paulus написал:
100 запросов в секунду — это не особо тяжелая нагрузка для сервера,тем более
на 8 ядрах.
а разве мускуль может рабоать в многоядерной системе? Судя по показаниям toр, то мускуль выполняется на одном ядре.
paulus написал:
Если хотите понять, на скольких RPS реально просаживается Ваш сервер —
стрельните в него ab и посмотрите, сколько он выдержит
ab ӕто какой-то бенчмарк?
идет в коплекте с мускулем или отдельно?
Неактивен
Если одна — это не пик нагрузки точно
FreeBSD — очень неудачный выбор для MySQL (и вообще? 
) — в ней отвратительная
тредовая библиотека. Возможно, это связано с ней. В других ОС (даже в виндоус)
MySQL тредится нормально и использует несколько ядер, разумеется.
ab — это apache benchmark, идет в комплекте с apache
--
P.S. К FreeBSD я отношусь предвзято, разумеется. Но в ней MySQL тоже должен тредиться —
попробуйте поднять нагрузку (например, пусть считает синусы в 100 потоков) — должно
быть больше 100% задействовано. Ну или в ps попросите просто показывать треды, чтобы
убедиться в этом.
Неактивен
попробовал натравить ab. показания Queries per second avg: растут очень медленно, серваку надо делать такую нагрузку наверное в течении 3 часов что бы увидеть реально положение дел. Я такое себе позоволить не могу как вы понимаете.
Я могу объяснить почему вдруг я создал эту тупую тему.
1) я плохо разбераюсь в тонкой настройке мускуля. всякие там буфера и кеши я не могу подстраивать. ну или почти не могу. совсем на минимальном уровне.
2) я хочу знать к чему стремиться. возможно есть вариант подстроить сервер и он будет обслуживать еще больше запросов.
3) меня все время упрекают в том что сервер может работать быстрее. Причем упрекают люди которые в этом не понимают вообще. Вот я и пытаюсь найти какое-то визуально отображение производительности сервера или выраженое в каких-то цифрах. Я же на эти упреки говорию что надо сперва избавиться от слов квери а потом уже мучать сервак. К слову говоря слов квери на серваке огромное количество на данный момент больше 7000, а максимально что я видел это около 20000. Вот и получается вечный конфлик программеров и админов, параллельно требуют и с программеров и с админов. Причем насколько я понимаю словквери появляются не из-за плохих настроек сервера, так как показания top и vmstat говорят о том что куча свободных ресурсов. Помню при неправильной настройке innodb_buffer_pool_size(было маленькое) сервак умирал.
Может посоветуете какую-то статью или книгу по настройке мускуля?
Отредактированно _Сергей (16.09.2009 13:42:19)
Неактивен
Сервер может работать быстрее только при сотрудничестве администраторов и программистов.
Силами одних администраторов, как правило, ничего сделать нельзя. Силами одних программистов
тоже, как правило, ничего сделать нельзя. Есть какие-то общие вещи, которые администратор
может подкрутить (innodb_buffer_pool_size, innodb_flush_log_at_trx_commit, etc), но глобально,
если запрос делает полный скан по таблице, то администратор с ним ничего сделать не сможет.
Если сервер легко справляется с нужным количеством запросов, то никаких проблем в том, что
количество запросов маленькое, я не вижу. Если же MySQL — узкое место, то тогда нужно,
конечно, пытаться оптимизировать запросы и базу. Как правило, плохи именно запросы, а не
настройки базы. Попробуйте включить slow log / not using indexes и посмотреть, какие запросы
попадают в этот журнал. Чтобы показать «сервер не нагружен, вам не нужно больше
производительности», можно показать, например, график load average.
Насчет книги, боюсь, что не подскажу — почитайте http://dev.mysql.com/doc/refman/5.1/en/ … tion.html,
там очень неплохо описан процесс оптимизации запросов.
Неактивен
