MySQL жрёт почти всю память на vps

Всем привет!
Ребят, кто в линуксе разбирается, помогите советом.

MySQL стал жрать много памяти. Почти всю отжирает, зараза.
Debian 7, mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (i686) using readline 6.2
256 МБ оперативной.

На сервере физически сайтов много, но это только для парковки доменов-зеркалов основного сайта. Реальных сайтов на сервере 2-3. На всех остальных никаких никаких cms не установлено. Посещаемость 150 человек в сутки максимум. Сайты простые, технологически не навороченны.
Раньше из 256 мегабайт отъедалось максимум две-третьих.
Но 2 дня назад начали сыпаться письма от хостера, что, мол, «памяти мало, делайте что-нибудь или платите больше». Платить-то мне не жалко, только вот за что? За 3 еле посещаемых сайта? Вот и хотелось бы разобраться.

Смотрел через htop — у мускула запущено много процессов. Сайты на сервер я добавляю через Васины bash-скрипты. Вот и возникли у меня подозрения, что на каждый «пустой» сайт mysql создаёт отдельный процесс и поэтому отжирает много всего.

Вопрос — как можно убить ненужные процессы mysql-я? Убить-то просто — в htop'е это легко.
Но как не убить нужный процесс? Как сделать, чтобы ненужные больше не запускались?

Буду благодарен любой подсказке!

upd. Сразу хочу сказать, что я гуглил. Гуглил много. И чем больше гуглил, тем понимал — настолько много разнообразной информации, которая меня запутала окончательно
Алексей Карташов
26 июня 2014, 13:00
modx.pro
4
18 687
0

Комментарии: 5

Abu
Abu
26 июня 2014, 20:28
0
Как-то оптимизировал свой локальный сервер, методом тыка — добавил такие параметры все личное ИМХО —
в /etc/mysql/my.cnf

skip-innodb
skip-bdb
skip-networking
default-storage-engine=myisam
query-cache-type=0
performance_schema = 0

Вроде еще процессы php-fpm нехило память отжирают — в конфигах

/etc/php5/fpm/pool.d/sitename.conf

вместо

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4

заменил на

pm = ondemand
pm.max_children=10
pm.process_idle_timeout=30
pm.max_requests = 50

Если я все правильно понял, менять для редко-используемых сайтов, процесс php-fpm не будет висеть в памяти, а будет запускаться только после запроса, наверняка уменьшает отклик php при первом запуске.
    Алексей Карташов
    26 июня 2014, 21:04
    0
    Спасибо за комментарий, сейчас буду пробовать. Только вот ненужные php-fpm процессы все вместе всё-равно кушают меньше, чем 10 mysql процессов.
    Т.е. пхп у ненужный сайтов я поотрубаю, но это лишь небольшой выигрышь. Основная проблема не решится(

    А не знаете как можно отрубить mysql для не нужный сайтов?
      Алексей Карташов
      27 июня 2014, 02:22
      +1
      В общем,
      на строке "skip-innodb" мускул падает и не хочет запускаться.
      Добавил в конфиг такие строки:
      query-cache-type = 1
      default-storage-engine = MyISAM
      innodb = off
      skip-networking
      skip-name-resolve
      skip-federated
      и о чудо! Отжираемая память _всех_ процессов (в т.ч. системных) упала до 90-100 МБ, т.е. примерно на 150-160 МБ. Чудеса)
      Благодаря вашему конфигу php-процессы тоже отрубаются, но чего-т их слишком много лишних, потом отключу. Результат и без того впечатляет!

      Спасибо большое!
      Alexander V
      27 июня 2014, 03:03
      0
      Вообще-то это нормально. Линукс держит в ОЗУ частые запросы, чтобы не дёргать диск. При этом повышается скорость работы.
        Boris
        24 апреля 2016, 03:51
        1
        0
        Та же история и на Ubunru 16.04 (версия MySql сервера: 5.7.11-0ubuntu6)
        по дефолту занимал 880 Мб памяти!!!
        Помогло это (стал занимать всего 140 Мб)
        skip-name-resolve
        skip-federated
        Но хотел бы попутно у профи Linux узнать, что это за зверь BIOSET ???
        Интуитивно что-то помнится, что это относится к дисковым операциям
        А смутил он потому, что
        в Ubuntu 15.10 этих процессов было всего 3
        а после обновления до Ubuntu 16.04
        их стало 27!!!
          Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
          5