Разное

Насколько я понял, потребности хостинга определяются требованиями той CMS, которую он обслуживает. Однако на практике все CMS делают примерно одно и тоже. И ресурсов они требуют просто жуткое количество!

Вот, например, как мне прокомментировала ситуацию техподдержка одной из них:

Давайте считать очень грубо. MySQL самый полный минимум с буферами 100 Мб, в норме хотя бы 400-500. Далее считаете максимальное количество одновременных процессов Apache и умножаете на выделенную память на процесс, например, 32 Мб. Что получаете 500 + 32*10 = почти 1000. Здесь мы не посчитали другое ПО, выполнили очень грубые допущения. Итого — минимум 1Гб.

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

Теоретически, как я понимаю, распределение зависит от типа преобладающих запросов. Но такой подход поставил в тупик самих создателей CMS, ибо они их не анализировали. Получается, что действовать приходится наугад.

Пока что я поступил так:

На РНР отведено 32 Мб.

Секция [myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M

Секция [mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
net_buffer_length = 2K
thread_stack = 128K
query_cache_size=5M


Это разумно?

>На РНР отведено 32 Мб.
Я так понимаю, это объем на один скрипт? Т.е. возможность прочитать одним куском file_get_contents() файл объемом 30Мб. Собственно, для ускорения работы скриптов нужно Apache ковырять, в PHP мало инструментов реально влияющих на нагрузку и распределение памяти.

>key_buffer_size = 16M
Это для всех сессий/соединений - лучше сделать побольше.
>sort_buffer_size, read_buffer_size, read_rnd_buffer_size
Это на каждую сессию/соединение, если оперативной памяти много, скажем 2Гб, то разумно. Однако, если у вас памяти 2Гб, то key_buffer_size - смело увеличивайте в 10-20 раз, иначе от индексирования таблиц будет мало толку.

С памятью действительно не все так просто... Большинство запросов выполняются меньше секунды, память выделяется и тут же отдается, поэтому за 1 секунду может выполняться огромное количество запросов от безумного количества посетителей. Т.е. сервер расчитан на 500 одновременных обращений, а де-факто их раз в 5 больше и все хорошо. Когда в эту идиалистическую картину влазят медленные запросы, а еще хуже незакрытые mysql-соединения, память обратно не возвращается и все запросы начинают ютиться на маленьком кусочке памяти - сервер начинает заваливаться, медленно обрабатывать запросы, от чего ситуация еще более ухудшается. Доходит до того, что пока к вашему серверу обращаются быстрые клиенты - все нормально, пришли модемщики с медленным соединением - сервер рухнул (ну если где-то есть большие документы, требующие открытого mysql-соединения, к счастью задача не частая).

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

Спасибо!

nginx поможет делу? В плане отсечения пользователей с медленной связью?

Его ресурсы тоже как-то задаются?

>nginx поможет делу? В плане отсечения пользователей с медленной связью?
Собственно, они (пользователи с медленной связью) не всегда критичны, грубо говоря ставьте mysql_close() в тех скриптах, которые генерируют "тяжелый" контент и проблема будет решена сама собой (за исключением ситуации, описанной в следующем абзаце). Собственно выяснить есть ли у вас такая проблема очень просто. Посмотрите список SQL-процессов (можно через phpMyAdmin) и если там пару десятков "спящих" (SLEEP) процессов? Если нет, то и проблемой этой озабачиваться не следует. Гораздо чаще память отъедают медленные запросы, которые выполняются по несколько секунд или дольше. Их тоже можно отловить, включив лог медленных запросов.

Если имеются большие файлы или какой-то скачиваемый контент (а часто и без оных) - гораздо более разумно ограничить количество одновременных соединений от одного пользователя. Пользователю конечно очень весело 50 потоками файл или сайт закачивать (хотя у него и при 3-х бы была таже самая скорость), а у вас на сервере под него отъедается 50 соединений Apache, которые перестают обслуживать других пользователей. А новые соединения требуют новой оперативной памяти. Если памяти мало, кто-то из запросов отправляется на диск, начинает работать медленно (в том числе заставляя ожидать (SLEEP) MySQL-запросы, которые тоже память держат).

Учитывая все эти особенности, невнятные ответы службы тех.поддержки понять можно, особенно если они не знают, что вы задумали, кто к вам будет ходить, что за ресурсы вы будете выкладывать на сайте, кто и каким образом их будет закачивать. А главное сколько народу будет. А на эти вопросы зачастую самому сложно ответить, не то что просвятить сторонних людей.

"если они не знают, что вы задумали"

Они знают, ибо я спрашиваю создателей о работе интернет-магазина на их CMS, которую они для этого и создавали. У меня сложилось впечатление, cheops, что никто так глубоко не копает, а делают как-то по наитию или вообще как придется.

Вот лично Вы, когда проектируете систему, задумываетесь над подобными вопросами?
Или у вас уже достаточно опыта для того, чтобы и так знать ответ?

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

>Вот лично Вы, когда проектируете систему, задумываетесь над подобными вопросами?
>Или у вас уже достаточно опыта для того, чтобы и так знать ответ?
Если ожидаю для сайта хорошую посещаемость (или на это специально обращается внимание в ТЗ), то да (стараюсь и базу данных искусственно создать большой, и подумать, и некоторые блоки подключить к посещаемому сайту, чтобы посмотреть на его поведение). Однако, что-то специально предпринимать стараюсь лишь в очевидных случаях, неочевидные, просто беру на заметку. Преждевременная оптимизация с 60-х годов считается бичом программирования - можно написать тонны бесполезного кода, да еще и ошибок туда насобачить, а узким местом окажется совершенно другой участок, о котором никто не думал.

а еще хуже незакрытые mysql-соединения,

Соединения с MySQL не закрываются при выгрузке скрипта?

Закрываются, но сам контент, который скрипт генерируется, пользователь может тянуть очень долго и пока он его тянет, соединение остается открытым. Если это обычная страничка, а скорость клиента высока - все хорошо, если отдается объемный файл, а пользователь имеет низкую скорость загрузки - плохо: соединение будет спать, выделенная ему память будет блокирована. Сотня таких клиентов - и половина памяти сервера заблокирована. Однако, повторю, что случай не частый, так как необходимо, чтобы скрипты отдавали большие файлы, при этом использующие соединение с базой данных, да еще не закрывающие соединение при помощи mysql_close(). Это крайний случай, большинство же реальных случаев промежуточные - т.е. страница размером 1Мб (привет JS-библиотекам), скорость у клиента может и приличная, но он помимо этого еще что-то качает, т.е. речь идет не о минутах, а о секундах (но все-равно не доли секунды).

>query_cache_size=5M
Это, кстати, тоже на всех - можно побольше сделать, но не сильно много (из расчета 50-100M на 2Гб оперативной памяти).

рассчеты ошибочны.