По крайней мере, то, что баг есть, а не мерещится и не битое железо и не выключение питания сервера пользователями, которым показалось, что "что-то плохо работает" :)
Там две баги, разработчики утверждают, что между собой не связаны, но у меня они вызываются одной и той же причиной - горячая таблица (текущее состояние источников данных) очень часто (~100 раз в секунду) апдейтится, параллельно ее читают из множества транзакций.
Оба бага чрезвычано редки и сложновоспроизводимы, возникают только на classic сервере, базу не калечат, первый лично для меня безвреден (мои воркеры умеют возобновлять работу после ошибок) но второй вызывает дичайший live-lock сервера, после которого ни одна вообще операция с ним не проходит, пока кушающий CPU процесс не прибьешь вручную.
Т.е. там сервер захватывает мьютекс, начинает кругами ходить по связному списку блокировок и не может выйти из этого процесса. Почему - а хрен его знает почему, мне пока не хватает времени попытаться изучить дампы памяти сервера и БД на момент live-lock всерьез, там надо вникнуть, как менеджер блокировок устроен для начала.
Угу. Программисты напоминают Сфинкса или пифий. Думаю, нет таких специальностей, где бы люди так же любили говорить загадками, как в информационных технологиях. Даже врачи и адвокаты при публичном общении переходят на человеческий язык.
Я вот не понимаю, почему люди всегда спрашивают "а почему бы не перейти на postgresql/mssql/oracle итд"
Это же переписать проект на 2/3 с нуля, собрать по дороге все грабли, переделать инсталляторы, тесты, переобучить весь обслуживащий персонал, полный повторный деплоймент у сотен клиентов, с миграцией данных и прочее такое. Оно встанет в непонятное количество раз дороже, чем разобраться с ошибкой в FB или обойти ее.
Ну и 4 гб - это как-то совсем мало, типичные размеры БД - 10-50 гб.
А техподдержка уже чонить на "корявый английский тикет" среагировала?
Помню микрософтовцев с их нередким "мы рады сообщить вам, что продолжаем улучшать критерии обслуживания вас, дорогого кастомера, и вашу багу мы подтверждаем, а в целях оптимизации наших усилий на особенно важных для наших кастомеров направлениях won't fix. Спасибо, надеемся на то, что наш продукт вам нравится."
no subject
no subject
no subject
no subject
Оба бага чрезвычано редки и сложновоспроизводимы, возникают только на classic сервере, базу не калечат, первый лично для меня безвреден (мои воркеры умеют возобновлять работу после ошибок) но второй вызывает дичайший live-lock сервера, после которого ни одна вообще операция с ним не проходит, пока кушающий CPU процесс не прибьешь вручную.
Т.е. там сервер захватывает мьютекс, начинает кругами ходить по связному списку блокировок и не может выйти из этого процесса. Почему - а хрен его знает почему, мне пока не хватает времени попытаться изучить дампы памяти сервера и БД на момент live-lock всерьез, там надо вникнуть, как менеджер блокировок устроен для начала.
no subject
no subject
Можно выделить четыре типа системных администраторов UNIX:
....
Ситуация 6. "Глупые" вопросы пользователей.
Технический бандит. Отвечает на вопросы в шестнадцатеричном или двоичном виде, иногда по-французки, пока пользователь не уходит.
Администратор-фашист. Блокирует вход пользователя в систему, пока тот не предоставит веские доказательства своей квалификации.
Маньяк.
# cat >> ~luser/.cshrc
alias vi 'rm \!*; unalias vi; grep -v BoZo ~/.cshrc > ~/.z;
mv -f ~/.z ~/.cshrc'
^D
Идиот. Отвечает на все вопросы в меру своего понимания. Приглашает пользователя в группу администрирования системы.
no subject
no subject
no subject
no subject
no subject
Это же переписать проект на 2/3 с нуля, собрать по дороге все грабли, переделать инсталляторы, тесты, переобучить весь обслуживащий персонал, полный повторный деплоймент у сотен клиентов, с миграцией данных и прочее такое.
Оно встанет в непонятное количество раз дороже, чем разобраться с ошибкой в FB или обойти ее.
Ну и 4 гб - это как-то совсем мало, типичные размеры БД - 10-50 гб.
no subject
А техподдержка уже чонить на "корявый английский тикет" среагировала?
Помню микрософтовцев с их нередким "мы рады сообщить вам, что продолжаем улучшать критерии обслуживания вас, дорогого кастомера, и вашу багу мы подтверждаем, а в целях оптимизации наших усилий на особенно важных для наших кастомеров направлениях won't fix. Спасибо, надеемся на то, что наш продукт вам нравится."
no subject
no subject