Как выявить какие запросы нагружают БД?

Ничего не ложит сайт, просто mysql неправильно настроен. На впске ему надо выделять 128 МБ памяти максимум.

1) пробуйте включить лог долгих запросов mysql

2) в момент проблем анализируйте работу mysql при помощи той же утилиты mytop

3) попробуйте попросить хостера оптимизировать mysql. Если откажутся и захотите все сделать самостоятельно, воспользуйтесь скриптом mysqltuner.pl (ВАЖНО: перед тем как менять тот или иной параметр, почитайте о нем информацию, чтобы понимать, для чего это делается и стоит ли это вообще делать)

Он не для случаев, когда памяти перебрали, хотя наверное и закричит, что памяти под mysql больше, чем оперативки выделено.

Тут наоборот, надо просто памяти уменьшить на все в my.cnf.

Хотя, я забыл, еще может быть, что памяти перебрал apache, а mysql убивают просто, как самого толстого. Так что в апаче тоже уменьшайте количество процессов и в php устанавливайте ограничения по памяти.

(а вообще php процесс для каждого сайта должен быть под разным юзером и в limits.conf ему должна быть ограничена память)

OOM говорит что сервер неправильно настроен. Ищи кто есть память и ограничивай.

учусь с putty работать, вот что в результате получил:

(хостинг 2 гига)

[mysqld]
myisam-recover=backup,force
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
max_connections=70
max_user_connections=30
wait_timeout=10
interactive_timeout=50
long_query_time=5
#log-queries-not-using-indexes
log-slow-queries=/var/log/mysql/log-slow-queries.log

key_buffer = 8M
myisam_sort_buffer_size = 32M
join_buffer_size=1M
read_buffer_size=1M
sort_buffer_size=2M
read_rnd_buffer_size=2M
table_cache=512
thread_cache_size=128
interactive_timeout=25
connect_timeout=5
max_allowed_packet=1M
max_connect_errors=1000
query_cache_limit=2M
query_cache_size=16M
query_cache_type=1
tmp_table_size=32M
max_heap_table_size=16M

#innodb_use_native_aio = 0
#innodb_file_per_table
innodb_log_file_size = 64M
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[client]

только что удалось запустить тюнер, пишет

 
[OK] Currently running supported MySQL version 5.5.45-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 302M (Tables: 413)
[--] Data in InnoDB tables: 8M (Tables: 96)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 0B (Tables: 14)
[!!] Total fragmented tables: 98

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 17m 12s (12K q [11.688 qps], 709 conn, TX: 128M, RX: 3M)
[--] Reads / Writes: 63% / 37%
[--] Total buffers: 184.0M global + 6.2M per thread (70 max threads)
[OK] Maximum possible memory usage: 621.5M (33% of installed RAM)
[OK] Slow queries: 0% (0/12K)
[OK] Highest usage of available connections: 4% (3/70)
[OK] Key buffer size / total MyISAM indexes: 8.0M/7.4M
[!!] Key buffer hit rate: 94.5% (59K cached / 3K reads)
[OK] Query cache efficiency: 47.8% (2K cached / 6K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[!!] Joins performed without indexes: 1052
[OK] Temporary tables created on disk: 14% (315 on disk / 2K total)
[OK] Thread cache hit rate: 99% (3 created / 709 connections)
[!!] Table cache hit rate: 7% (223 open / 2K opened)
[OK] Open file limit used: 17% (193/1K)
[OK] Table locks acquired immediately: 100% (10K immediate / 10K locks)
[OK] InnoDB buffer pool / data size: 128.0M/8.9M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Adjust your join queries to always utilize indexes
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://*******/1mi7c4C
Variables to adjust:
    join_buffer_size (> 1.0M, or always use indexes with joins)
    table_open_cache (> 512)

по поводу оптимизации и дефрагментации таблиц - я это регулярно стал делать, они всеравно крашатся. лог запросов только что включил..

Кстати вот еще что пхпмайадмин пишет:

в одной из баз есть таблица с 15 тысячами записями. суточная посещаемость всех сайтов около 7-8к. Однако фактически ВПС ложится зачастую ночью. Впрочем в любое время суток. Но около 4-5 утра достаточно часто пробуждаюсь от смсок...т.е. это не от посещаемости. в логах какие-то сортировки были, когда писал хостеру.

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

---------- Добавлено 06.10.2015 в 14:48 ----------

Увеличить или уменьшать настройки?

прошло несколько часов работы mysqltuner

подскажите что с этим делать? пишут что надо увеличивать, но выше писали, что наоборот надо ограничивать. Кстати там совет оптимизировать и починить таблицы- я это сделал. а они видимо опять..

Здравствуйте.

Можно бесконечно пытаться что-то сделать тыкаясь наобум. Это редко приводит к успеху.

Если позволите, могу предложить за небольшую цену решить ваши проблемы. Могу гарантировать, что после пары дней мониторинга смогу исправить ситуацию.

Сервер надо оптимизировать, это факт. По данной информации, можно попробовать его еще покрутить. Тут еще один момент, если он падает по ночам, проверьте задачи планировщика. Может там какой парсер или еще что-то срабатывает, что грузит базу и ложит ее.

Ничего с этим не делать.

У вас процесс mysql прибивается оом киллером, это значит, что какой-то процесс просит больше памяти, но памяти нет и кого-то нужно прибить и забрать у него память. Есть два алгоритма кого прибивать: того кто просит или кого-то другого, кого система посчитает самым ненужным. Чаще второй алгоритм включен, потому что он позволяет постепенную деградацию (правда ему нужен супервизор чтобы подкручивать oom_adj под конкретную задачу, чтобы не убивал mysql, например). Можно проверить какой алгоритм включен выполнив cat /proc/sys/vm/oom_kill_allocating_task, если там 0, то работает именно второй алгоритм.

Предположим, что второй. Тогда mysql точно не причина и решений может быть несколько:

1. Перейти на первый алгоритм (записать в /proc/sys/vm/oom_kill_allocating_task единичку) и тогда будет прибиваться тот процесс, который просит больше памяти.

2. Настроить оом для автоматической перезагрузки сервера при срабатывании. Он такое умеет.

3. Найти, какие процессы плодятся и едят много памяти и поубавить их аппетиты. Возможно это apache, потому что у него идиотские настройки по умолчанию, которые позволяют плодить много процессов просто от обращений к нему.

Если вдруг алгоритм первый, то в my.cnf просто поуменьшать память на все.

На графике падение начинается всего при 650Мб занятой памяти. И своп всегда равен нулю. Имхо, дело не в Мускуле, как и сказали выше.