Одминский блог

Настраиваем MySQL для работы на VPS с 512Mb RAM

Прикупил я тут клиенту хостинг под его новый сайт. Поскольку была необходимость в прикручивании библиотеки ffmpeg на сайт под Drupal, для того чтобы видюшки конвертились сами во флешки при добавлении, хотя для меня это не убедительно, так как на локальном компе можно нормально законвертить ручками. Ну вообщем по причине наличия ffmpeg решил взять самый дешевый VPS за 5,95$ у Burst.NET с 512 оперативы, 1MHz, 20Gb HDD, 10Tb трафа и 2IP + Direct Admin за 7$, так как настраивать руками меня ломало.

Взять то я его взял, но вебмастера не могли ничего делать, так как на любую операцию система ругалась:
ERROR 1135 (HY000): Can’t create a new thread (errno 11); if you are not out of available memory
gzip: error while loading shared libraries: cannot create cache for search path: Cannot allocate memory
подключившись, я обнаружил что при попытке логина по ssh вылетала ошибка:
bash: fork: Cannot allocate memory

То бишь сделать ничего мог, так что отписался суппорту, что вот есть проблема с серваком. так что решите плиз. Суппорт же начал меня грузить на предмет того, что мне надо с апгрейтиться до 1Gb чтобы у меня все стало отлично, так как ось и Direct Admin отжирают все 512Mb. Я же давил на то, что top, к которому я таке смог пробиться показывает что занято всего 42% памяти и значит парни не тока оверселят, но еще и оверлодят память.

В таком духе мы препирались часов 5, поскольку мне некогда было лезть и особо разбираться. Я пару раз обложил в сердцах суппорт матюгами, после чего они начинали шевелиться быстрее, но все равно начинали втулять мне необходимость покупки 1Gb. Хотя по началу я хотел забрать бабло, накатать абузу в палку, в итоге во втором часу решил все таки глянуть более предметно, что происходит. Кстати в этом ключе- суппорт вещь такая- буквально в парралель  меня упал мой VPS и если честно я решил что это месть Burst, но оказалось что там была проблема с диском и другой чувак мне все замечательно и быстро решил, тем более что я конечно нервничал, так как буквально на этой неделе запилил два симпотных сайта, а бэкап датировался естественно началом сентября.

Ну вообщем сунулся кое как в сервак и понял, что мускуль кушает под себя 360Mb, так как грузится без файла конфигурации. Уж не знаю- толи забыли создать при первоначальной настройке, толи удалили в сердцах вебмастера, но пришлось озадачиться тюнингом MySQL под сервер с 512M, поместив в файл /etc/my.cnf следующие строки:
[mysqld]
local-infile=0
socket = /var/lib/mysql/mysql.sock
max_connections=300
slow-query-log
query_cache_limit=16M
query_cache_size=32M
key_buffer=16M
sort_buffer=64M
read_buffer = 2M
read_rnd_buffer_size = 768k
read_buffer_size=64M
max_allowed_packet=16M
thread_stack = 128K
skip-innodb
table_cache = 64M
Поскольку у меня оказалась InnoDB (правда не совсем понятно с какой целью мне ее прикрутили, хотя вебмастеров по форумам я именно ей и пугал при разговорах о горячем бэкапе), то пришлось поиграться с её параметрами, так как стандартные в 50-80% от RAM для innodb_buffer_pool_size забивали систему под 500 Mb, и в этом случае параметр skip-innodb убирается
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M

После перезагрузки система зашуршала, отбирая под себя 440Mb.

Пришлось еще повыкидывать несколько параметров, так что файл приобрел вид:
[mysqld]
local-infile=0
max_connections=300
read_buffer_size=1M
sort_buffer=1M
log-slow-queries
query_cache_limit=256K
key_buffer=1M
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M
max_allowed_packet=16M

После чего система стартанула уже с 350Mb, с которыми уже можно было в принципе жить.

Хостинг конечно хороший, но как попадешь на тупаря в суппорте, так хоть стой, хоть падай.

Теги: mysql, сайты, хостинг