У нас оборотов в миллионы нет, мы для них обычные клиенты. И скорее всего мы говорим о разных дата центрах.
Осталось железо в Online SAS, там за то время, что нас не было, немногое поменялось. В случае нестандартной ситуации выловить поддержку сложно.
Сам факт повышенного шанса повреждения базы данных не радует. Поэтому такое точно использовать не буду.
Во Франции тоже свои тонкости есть. Раз ведь пролежали 4 часа и это просто повезло. Могли вплоть до суток лежать. Сейчас, считаю, в текущей политической ситуации лучше остаться в России. Во Франции в будущем будет небольшая площадка, но это где-то не раньше лета.
Кроме PHP и MySQL ничем не прыгали, всё остальное стоит из коробки.
Убрать попробовать можно, попытка не пытка. Так как всё что можно было перепробовано уже.
innodb_flush_log_at_trx_commit на мой взгляд не безопасно. Хоть сервер стоит и в ДЦ, но никаких ИБП и RAID контроллера с батарейкой нет, чтобы такое ставить.
Уважаемые пользователи, с сожалением сообщаем Вам о грядущем повышении цен с 1 апреля. Для старых клиентов стоимость возрастет на 30%, для новых заказов стоимость возрастет на 50%. Повышение цен связано с повышением цен в полтора раза нашим дата центром еще в феврале.
Обращу Ваше внимание, что тем, кто оплатил услуги на длительный период ничего не придется доплачивать. Новые цены Вас затронут только при следующей оплате. В течение марта все желающие также могут оплатить услуги наперед, но не более чем на год. Чтобы зафиксировать цены на ближайшее время.
Ввиду сложившейся ситуации мы произвели некоторые изменения в распределении ресурсов между клиентами. На некоторых тарифах сайты стали работать более чем в два раза быстрее!
Подробнее с изменениями Вы можете ознакомиться в нашем сообществе в ВК: https://vk.com/page-54441939_50293316
Исходя из письма Вы можете забрать резервные копии (если они делались через панель) через их тикеты. Цитирую:
По сути это сервер с огромным числом сайтов на Joomla, Drupal, WordPress и возможно чем-то самописным. MySQL строго настроен на использование 1/3 памяти сервера за пределы которого и не вылезает даже при 300 активных соединениях. По практике, если бы проблема была в запросах, то они просто бы тупили, но 1 запрос никак не мог бы вызывать очередь из 300 соединений и в какой-то степени положить MySQL.---------- Добавлено 04.03.2015 в 16:09 ----------
Понятия не имею, за скрипты которые используются на сервере ответственности не несу и лезть мне в них нельзя. Моя задача только в том, чтобы сервер хорошо работал и эти скрипты хорошо работали.
Если где-то в статистике можно посмотреть число commit's, то ткните пальцем, посмотрю :)---------- Добавлено 04.03.2015 в 16:20 ----------
MySQL собрался из исходников с официального сайта. MySQL 5.1 уже как-то слишком устарел на мой взгляд и 5.5 отлично работал и работает на CentOS 6.6, только не на этом сервере...
Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.
По skip-innodb-doublewrite ситуация такова. tmp папка вынесена в оперативную память и там O_DIRECT не работает корректно, лог заваливается ошибками:
В качестве аналога для O_DIRECT и включили skip-innodb-doublewrite.
Пробовали и без него тоже, это было добавлено недавно. Изначально, когда проблем еще не было, конфигурационный файл был еще куда проще:
[mysqld] character-set-server=utf8 init-connect='SET NAMES utf8' collation-server=utf8_general_ci local-infile = 0 tmpdir = /dev/shm # Буферы sort_buffer_size = 4M join_buffer_size = 4M read_buffer_size = 4M read_rnd_buffer_size = 4M # Оптимизация производительности key_buffer_size = 2G tmp_table_size = 128M max_heap_table_size = 128M query_cache_size = 128M max_connections = 300 max_user_connections = 32 # InnoDB innodb_log_file_size = 128M innodb_additional_mem_pool_size = 32M innodb_flush_log_at_trx_commit = 2 innodb_buffer_pool_size = 4G innodb_file_per_table
Данный типовой конфиг стоит на десятках серверов и проблем нет. А на этом вот закрылась проблема. С этим конфигурационным файлом и опцией table_open_cache тоже происходит утечка памяти, с этого так скажем всё и начиналось. Опцию убрали, стали запросы вешаться в query end.
Лимит открытых файлов достаточно высок, в этом не может быть проблемы:
fs.file-max = 3275006
Для наглядности график соединений и памяти.
Ткну пальцем, так как видимо не уловили Ваше сообщение.
echo value > /proc/sys/dev/raid/speed_limit_min
Где value минимальная скорость в кб\с для синхронизации. Но учитывайте, что если поднять слишком высоко, система может начать сильно тупить.
Добрый день.
Напишите в отдел продаж тикет или письмо - сделаем для Вас :) А так, не ожидалось, сейчас немного не до них...
