Что это у вас? VPS или же выделенный сервер? Если первое, то быть может вы столкнулись с недобросовестным хостером, который сдал вам памяти больше, чем у него есть.
А вообще, как минимум, mysql на каждое соединение расходует n памяти. Чем больше таких соединений одновременно, тем больше памяти он начинает кушать.
Более того, после работы соединение ещё какое-то время висит в ожидании активности (28800 секунд по умолчанию) прежде чем закрывается.
Вам необходимо грамотно настроить mysql основываясь на количестве памяти, которую имеет ваш сервер.
Также возможно утечки памяти есть и в коде. Пока видно, что память у вас жрёт именно mysql, который занят обработкой запросов...
Поставьте mysqltuner, с помощью него сможете увидеть достаточно детальную статистику работы mysql, по которой станет понятнее что происходит.
Также тюнер даст базовые рекомендации, что необходимо исправить в конфигурации мускл, правда слепо следовать его рекомендациям нельзя...
Совет вредный. С параметрами надо не играться, а подбирать опытным путём с обязательным пониманием того, что вы делаете.
ТС вряд ли осилит эту задачу самостоятельно. Также следует отключить InnoDB если оно не используется. А вообще всей ситуации
никто из нас не знает... Я бы порекомендовал ТСу нанять админа, который разберётся в ситуации на конкретном сервере.
Сделать это можно в соответствующем разделе данного форума. Также проблема может быть совсем не по вине сервера...
KVM вам поможет если у вас хостер недобросовестный и сдавал вам ресурсы, которых у него реально нет. OpenVZ это позволяет. Но я бы бежал от такого хостера
далеко далеко и чем быстрее, тем лучше. А вот реально поможет или нет зависит от того в чём же реально причина. Мы тут все лишь гадаем, никто не видел
вашего сервера и никто не может знать наверняка.
Restart=always RestartSec=10s
Автоматически перезапускает службу, если она была остановлена. Так что да, этот костыль вам поможет. Но вам надо устранять причину, а не последствия...
В логе только информация о том, что служба mariadb запущена по вашей команде start, больше там нет ничего. Т.е непонятно почему она оказывается остановленной.
Это исходя из того, что вы говорите, что остальной лог идентичен... В совокупности с тем, что таблички повреждены, думаю что эта остановка непредвиденная,
т.е службу кто-то нагло убивает. Скорее всего OOM killer, которые начинает убивать службы если в системе не остаётся свободной оперативной памяти.
Учитывая что памяти у вас всего 1гб и то, что это OpenVZ скорее всего так и есть.
Память смотреть: free -m (показывает в реальном времени)
Странно, что /var/log/messages нет. А /var/log/syslog есть? Если есть, сделайте cat /var/log/syslog | grep -i "oom"
Если InnoDB не используется и не нужен, да отключить в целях экономии памяти. Но есть нюансы, т.к в 5.5 это движок по умолчанию,
надо указать соотв. настройки, которые сделают MyISAM движком по умолчанию.
Можно будет использовать. На скорость? Повлияет... Не в лучшую сторону. Linux будет производительнее. Тем более если грамотно подойти к выбору софта и хорошо его настроить...
Приветствую.
Смысла в этом нет. На Linux есть всё, что необходимо для максимально быстрой работы вашего WP.
Более того, скорее всего хостеры с вас потребуют доп. оплату за лицензию для Win.
А на Win обычно ставят то, что просто физически не способно работать где-то ещё...
Что удобнее лично вам то и ставьте. Только не Ubuntu, а Debian уж тогда (надёжнее и стабильнее).
Dram у поисковых ботов гораздо больше ip, плюс они меняются, невозможно заготовить список на всю жизнь.
Они рекомендуют проверять обратный DNS-запрос IP-адреса через host. Но это вручную, конечно. А так необходимо искать другие решения для автоматизации.
Вам действительно нужен такой innodb_buffer_pool_size? или вы его просто поставили?
А вообще рекомендую перевести таблички в MyISAM и отключить InnoDB вовсе, если позволяет ситуация. Включить Swap, если он отключен.
Вам необходимо грамотно настроить ваш сервер, как минимум mysql точно.
Стандартные настройки хорошо, но они не подходят для реальных задач.
mysqltuner вам в помощь, но делайте всё с умом, не надо ставить огромные значения,
также как и не всегда стоит слепо следовать рекомендациям тюннера.
Далее ваш SELECT затронул 1.4млн строк, это не есть хорошо.
Проверьте его через EXPLAIN, убедитесь чтобы запрос использовал индексы.
Если индексов в базе нет, то обязательно добавьте их где не хватает.
Точно так-же и с остальными медленными запросами.
