Fastvps.ru - Благодарности! / 6

michaek, вроде как клиент не указывал сроков. А большое количество записей может быть за какой угодно период.

Ну так или иначе это всего лишь теория.

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

как всегда и бывает: кроилово ведет к попадалову

Relapse, сожалею, что Вы столкнулись с подобной ситуацией. Насколько я вижу, в тикете #966388 Вам уже подробно объяснили ситуацию. Повторю это объяснение на форуме:

К сожалению, на хост-сервере, на котором расположен Ваш сервер, действительно произошел сбой, а именно kernel panic. Подобной ситуации предсказать нельзя, она происходит внезапно, из-за какой-либо ошибки в ядре ОС, поэтому работу идут внеплановые (т.е. не запланированные). Сами работы заключаются в сохранении crash-дампа, аппаратной перезагрузки хост-сервера, загрузки хост-сервера с последних стабильных версий ПО, и корректного запуска клиентских контейнеров.

Сам kernel panic это сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу. Т.е. происходит аварийная остановка работы всех процессов хост-сервера и процессов виртуальных серверов. При этом действительно может происходить потеря данных, которые не были успешно записаны на диск, так как процесс записи данных немного сложнее, чем просто "взяли и записали". Грубо говоря, ОС Linux оперирует различными буферами и кэшами при работе с данными для ускорения с ними. Помимо этого у приложений есть также свои механизмы для оптимизации работы с дисковой подсистемой.

На примере сервера MySQL:

Ознакомиться как именно MySQL работает с диском и какие опции для изменения этого поведения есть у сервера MySQL можно в документации по ссылкам https://dev.mysql.com/doc/refman/5.7/en/innodb-disk-io.html и https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-diskio.html

По умолчанию, сервер MySQL пишет и читает данные в RAM памяти и периодически эти данные из памяти сбрасываются на диск. Помимо этого есть также буферы файловой системы, планировщик I/O в ОС, которые в итоге также влияют на итоговый реальный момент сброса (записи) данных на диск. Если в момент, когда сервер MySQL изменил данные в буферах, но еще не произвел сброс данных на диск, произойдет крах процесса MySQL (или всей ОС (как kernel panic на хост-сервере) или обесточивание сервера), то данные, находящиеся в буферах, будут полностью утеряны.

К сожалению, от kernel panic застраховаться не возможно, идеального безошибочного ПО, такой сложности как ядро Linux, нет. Хочу обратить внимание, что от ошибок не застрахована и аппаратная часть, например http://www.computerra.ru/138414/intel-skylake-cpu-bugs/

Снизить риски потери данных при таких ситуациях можно различными методами (в том числе и в комплексе), например более тонкой настройкой сервера MySQL, например корректировкой флагов innodb_flush_method, innodb_flush_log_at_trx_commit и прочих. Также можно настроить репликацию данных сервера MySQL на резервный сервер. Для исключения влияния системы виртуализации мы можем порекомендовать использовать выделенный физический сервер, что позволит отказаться от дополнительной программной прослойки, которая также может вносить вероятность ошибки (если рассматривать выделенный физический сервер и выделенный виртуальный сервер, то под виртуальным сервером есть еще программная прослойка, обеспечивающая работу виртуальных серверов).

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

Мы искренне приносим извинения за неудобства, которые были Вам доставлены из-за падения хост-сервера. Мы прикладываем максимум усилий для минимизации подобных ситуаций и активно сотрудничаем с производителем используемой у нас системы виртуализации для исправления всех найденных ошибок и не допущения их в будущем. За последний год нашими инженерами было зафиксировано и сообщено около 300 проблем, информацию можно найти в баг-трекере https://bugs.openvz.org/

Благодарим Вас за выбор FASTVPS.

kovalkov, спасибо за подробное разъяснение проблемы.

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

Relapse, к сожалению, предсказать kernel panic (на примере Windows - синий экран смерти, BSOD) возможности никакой нет, поэтому мы не можем заранее предупредить наших клиентов о надвигающейся проблеме. Для нас она также неожиданна, как и для Вас.

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

kovalkov, понял вас.

Еще раз спасибо за ответы и за компенсацию по двум серверам.

Продолжаю работать с данным хостингом, рекомендую

собираюсь взять VPS РФ. Там предзаказ сейчас. Насколько я понимаю, услуга новая и необкатанная. Прошу представителей FastVPS подсказать здесь - гарантия стабильности будет? Понятно, что никто не застрахован от неожиданностей, но все же хотелось бы увидеть ваше мнение по поводу ВПС в РФ :) Ну и написано, что есть 2 месяца бесплатных, это кул

REA-white, спасибо за Ваш интерес к нашим услугам! Услуга не новая и уже обкатанная, просто текущее оборудование ресурс по количеству VPS исчерпало, в данный момент ожидаем поставки нового хост-сервера.

Прошу подсказки:

есть VPS на старом тарифе вероятно с обычным HDD и 4 ядрами процессора Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

Есть желание переехать на тариф с SSD, но процессор там тот же, но уже 2х ядерный.

Что будет производительнее: текущий вариант или новый?