Вход
Регистрация
("Progress update: restoring tranquility to tranquility")
Оригинал: http://www.eveonline...?a=blog&bid=737 от CCP Valar:
Начиная с 25 ноября 2009 года, за несколько дней до установки Доминиона, мы переживали частые незапланированные перезагрузки Транквилити. Почти все из них случались из-за бага в сетевой подсистеме, который вызывал отказ SQL-сервера.
Почему же - почему, и что Вы с этим всем делаете?
Как только случился первый отказ, мы согласно нашей стратегии, открыли прецедент для тех.поддержки поставщика относительно инцидента, т.к. наши логи, к удивлению, ничего не показали. Их ответ был следующим: проблема была вызвана состязанием сигналов в системе*.
Мы плотно поработали с тех.поддержкой поставщика, и группы разработки в попытке исключить этот баг собрали громаднейшее количество диагностических данных и применили изменения, которые рассматривались поставщиком, как потенциальные решения. Мы верим, что мы нашли путь обхода, при котором баг будет запускаться с малой вероятностью, но не предотвратили его появление на 100%. Однако это еще надо подтвердить.
Как все могут себе представить, трудно диагностировать такую действующую высокопроизводительную среду, как наша, без вызова лагов или других проявлений, или проблем с надежностью. Поставщик усердно работал, стараясь воспроизвести этот случай в своей лаборатории, хотя сбор диагностических данных с похожих систем ставил важнейшую задачу: сделать это без негативного воздействия на уровень производительности в восприятии клиентов.
У нас, всё же, есть программисты и системные администраторы виртуального мира, которые работают над сбором тестового скрипта ,чтобы запустить его на сервере БД, который мы используем для Singularity и Multiplicity, и если у нас получится воспроизвести этот случай там, мы сможем предоставить поставщику код, который воспроизведет проблему в их лаборатории.
Я персонально потратил достаточно большую часть рабочего времени за последние 3 месяца, общаясь напрямую с поставщиком, собирая диагностические данные, настраивая инструменты сбора и работая над вещами, связанными с решением проблем SQL-сервера.
Короче говоря, мы используем все ресурсы, которые есть в нашем распоряжении, чтобы решить проблему. Это высокоприоритетная проблема для всех наших групп, вовлеченных, т.к. это воздействует не только на наши системы и клиентов, но также может воздействовать и на огромные системы и пользовательские базы, использующие схожие сетевые решения и решения для баз данных.
Что мы уже сделали? Что мы уже знаем?
Мы знаем, что проблема кроется в стеке TCP, и, похоже, что надо что-то сделать с управлением закрытыми сокетами или их закрытием. Наш поставщик попросил нас применить некоторые потенциальные исправления и пути обхода. Мы отрегулировали некоторые сетевые особенности и проапгрейдили движок SQL-сервера до той версии, где есть пути обхода для случаев подобной природы. Манипулятор баз данных в серверном приложении EVE использует сеансовый пул, и мы уже экспериментировали с различными настройками в нем. Выключение переработки подвисших сессий кажется многообещающим как обходной путь, делающий запуск бага менее вероятным.
Мы все еще работаем над исправлением, как я уже сказал, и, кажется, мы сможем сделать отказы менее частыми с последними изменениями. Ждите новых объявлений о прогрессе в этом направлении в ближайшем будущем.
- CCP Valar
* состязание сигналов – это проблема возникающая, как в электронике, так и в сетевых технологиях, и в программном обеспечении. Русская вики дает скромное описание, но зато пару полезных ссылок. Английская вики описывает более подробно: Race condition.
Вчера на сингулярити опять был большой тест… Возможно, CCP что-то и смогло найти.
Наверх
