1111111111Rating 4.00 (5 Votes)

За счет MySQL как оказалось можно снизить потребляемое количество ОЗУ практически на 100Мб (+-) заранее хотелось бы сказать, что у MySQL есть файлы предустановленых конфигураций:

  • my-small.cnf — для систем с малым обьемом памяти, меньше 64Мб
  • my-medium.cnf — если памяти мало от 32 до 64Мб), где MySQL используется совместно с другими приложениями (к примеру Apache) и с памятью около 128Мб
  • my-large.cnf, my-huge.cnf — для систем с большим обьемом памяти (512Мб, 1024Мб), где MySQL играет главную роль.
  • my-innodb-heavy-4G.cnf — 4Гб памяти, InnoDB, где MySQL играет главную роль.

Данные конфигурации расположены здесь:

/usr/share/doc/mysql-server-x.x.x

Для VPS оптимальным будет являться my-medium.cnf, в данном случае нам нужна секция [mysqld]:

[mysqld]
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K

данная концигурация более подходит для серверов с 256Мб ОЗУ, подправим их с учетом для сервера с 512Мб ОЗУ можно добавить \ изменить пару настроек:

key_buffer_size = 64M
table_open_cache = 512
record_buffer = 1M
max_connections = 100
sort_buffer_size = 32M
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1
thread_cache_size = 4

елси у VPS меньшее кол-во памяти (к примеру 384) то можно уменьшить значения key_buffer_size до 32M, table_open_cache до 32, query_cache_size до 32M (данными параметрами можно варьировать в зависимости от ситуации), далее если не используется InnoDB то в эту же секцию добавляем:

skip-innodb

Примечание: после обновления на mysql 5.5 эта директива перестала работать

У меня взаимодействие с MySQL происходит через сокет, поэтому можно добавить параметр:

skip-networking

Касательно зависимости ситуаций, здесь для более точной диагностики можно использовать скрипты, результат работы которых, будет сообщать о тех или иных некорректных параметрах, благодаря к примеру скрипту mysqltuner.pl мне удалось добиться практически оптимальных результатов для моего MySQL, хотелось бы отметить, что ключевыми параметрами для потребления памяти являются - key_buffer_size и max_connections, чем больше значения, тем больше памяти будет расходоваться, в конечном итоге, сервер может просто встать, что и было в моем случае на первых порах...

Итак - tuning-primer.sh, загружаем:

wget http://day32.com/MySQL/tuning-primer.sh

меняем разрешения:

chmod u+x tuning-primer.sh

запускаем:

./tuning-primer.sh

mysqltuner.pl, загружаем:

wget http://mysqltuner.com/mysqltuner.pl

меняем разрешения:

chmod +x mysqltuner.pl

запускаем:

./mysqltuner.pl

После всех манипуляций, дефрагментируем таблицы:

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

если выдаст ошибку вида:

mysqlcheck doesn't support multiple contradicting commands

то необходимо попробовать:

mysqlcheck -u root -p --auto-repair --optimize --all-databases

 

Добавить комментарий


Обновить
Защитный код

Сейчас 76 гостей и ни одного зарегистрированного пользователя на сайте

Вверх
Вниз