Во Франции тоже свои тонкости есть. Раз ведь пролежали 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 минимальная скорость в кб\с для синхронизации. Но учитывайте, что если поднять слишком высоко, система может начать сильно тупить.
Добрый день.
Напишите в отдел продаж тикет или письмо - сделаем для Вас :) А так, не ожидалось, сейчас немного не до них...
У Вас именно в течение 4 лет убытки и нервы были? 😂 Вы видимо из тех клиентов, кто не делает резервные копии?
Ситуации бывают разные, в данном случае можно сказать у них отжали оборудование (если не ошибаюсь). Посмотрел бы я на Вас, будучи Вы владельцем компании, что бы Вы предприняли. Возврат средств? Сомневаюсь :)
Поэтому, я скажу так - данная компенсация, это лучше, чем ничего, поверьте. Компания свои ошибки поняла и приняла, выводы сделала. работают 5 лет без проблем.
Всем доброго дня.
Являюсь пострадавшим от 2010 года. Увидев данный топик, так скажем, написал наудачу Игорю Белову предоставив данные от аккаунта 2010 года. Не ожидал, но Игорь попросил зарегистрировать аккаунт на сайте их партнера vdsina.ru и зачислил средства на него.
С учетом того, что я до сих пор был зол на них - это вполне такой неплохой бонус от них.
А так, если смотреть в долгосрочной перспективе, то в течение можно сказать 5 лет у них проблем больше не было, можно потестировать vdsina.ru и если всё нормально задумываться уже и о приобретении услуг у mchost.ru
