Comments 10
Мало что понял, но уважаю тех, кто не отбрасывает случаи 1 на миллион. Если все были бы такими, авось и жизнь стала бы лучше.
А то там чуть недоглядели, там схалтурили, а в сумме получается жигуль вместо мерседеса.
В целом поддерживаю посыл, но в данном конкретном случае это был не "одноразовый баг", а тотальный блокер. Нельзя поставлять потребителю СХД, которая под нагрузкой по нескольку раз в час вешает хост-системе операцию I/O на 10 секунд. Это будет обнаружено заказчиком, прослежено до СХД и заказчик сразу выкатит претензию (и вообще любой нормальный заказчик, получив неизвестную ему модель СХД, сначала проведет те же нагрузочные тесты, чтобы понять, какую нагрузку туда можно давать в продакшне и на что рассчитывать - и сразу же наткнется на эти выбросы).
Это все замечательно. Но как простому юзеру понять что у него плохой кабель и его нужно заменить ? Это у вас были глюки 1 на 150 млн, а ведь у кого-нибудь они могут оказатся намного более частыми, может быть это даже скажется на производительности в целом. Они не смогут вычислить проблему самостоятельно, а вместо этого будут ругать ваше изделие.
Это комплексный вопрос. Обвинять что-либо — это строить гипотезы без их подтверждения.
Необходимо собрать как можно больше данных как из окружения пользователя, так и с СХД. Чтобы реализовать первое, Вам понадобится некоторая экспертиза с Вашей стороны. Для сбора данных с СХД необходима помощь технической поддержки вендора. Естественно, скорому достижению результата способствует взаимопонимание и сотрудничество.
одна из статей, которые читаешь, как детектив :)
Хорошая статья, понравилось. Заодно узнал много интересного и полезногопро устройство IO в Линуксе, особенно про его стек.
На предмет бура "глубокого бурения", ну .. его встроенность явилась одной из причин расставания с последним местом - вебстудией, таких историй - вагон и маленькая тележка .. "почему крон-джоба работает, но метрику пишет кривую?", "почему превью дизайнера делается не всегда, хотя задание отмечается как исполнено?" .. последнее было самое зачетное:
ПХП конечный автомат, который по заданию, к заданному макету делал нужные превью в заданных разрешениях. Система досталась "как есть", авторов уже нет, проблема давняя, но не критичная .. но, когда полез смотреть, то оказалось что кроме этой проблемы, задания часто "пропадают" и на них смотрят сквозь пальцы: не сделалось, да и ладно, повторим.. пропавшие задания тем временем молча копились в очередях Gearman, занимая место .. к моменту открытия было 12 тысяч "потеряшек" и 75% занятого места на дисках.. по ходу расследования нашлась ещё кучка проблем, исправленных оперативно, но .. задания так и выполнялись "липово"!
По итогу: схема оказалась такой: Задание ставилось в "очередь" таблицу БД, откуда вытаскивалось, менялся статус и оно отправлялось брокеру очередей. Брокер очереди имел подписанного исполнителя (двух, иногда трех) которым отдавал задание. Исполнитель был физически один - "машина главбуха" как самая крутая на момент создания системы (позже про этот нюанс все забыли) но, с динамической оценкой загрузки и мог подписывать ещё исполнителей от себя .. это и стало главным тупиком расследования: этот исполнитель после мелких доработок работал без нареканий, нет "потеряшек" в его логе ни одного!
И только после того, как ему принудительно было сказано подписываться однократно в системе .. обнаружился второй исполнитель, кто, откуда? Изучение сетевой архитектуры вывело на .. машину бывшего разработчика, стоящую в серверной и тихо продолжавшей работать уже как с год! Про неё админ забыл просто.. и вот как раз на ней, в целях отладки, был все ещё запущен исполнитель "тест", который принимал задание, ничего не делал, но отвечал "ок" .. вот они - "потеряшки"!
Всё расследование совокупно заняло около месяца..
Крутое расследование!
Не знаю, как в вашем случае, но обычно такие штуки, очень непростые (хотя и увлекательные) руководством оцениваются "да, молодец, но нам надо вот эту фичу вообще-то..."
В целом подобные задачи не являются целевыми для программистов, по крайней мере на начальном этапе анализа, пока нет четкого понимания вызвано ли наблюдаемое явление нежелательным поведением кода, аппаратной платформы, либо средой, в которой производится тестирование. Когда проблема локализована, редуцирован сценарий воспроизведения, она может быть оформлена как заявка на исправление ошибки или улучшение, т.е. передана в команду разработки.
Странно, что драйвер не выдал никаких ошибок без включения расширенного логгирования, ведь в FC каждый фрейм на счету и такие штуки должны ловиться USE методом.
USE это верный подход. Но, как ни странно, по умолчанию ql2xextended_error_logging = 0, а для регистрации check condition со стороны инициатора необходим ql_dbg_io () + ql_dbg_buffer
...
qla2x00_handle_sense(srb_t *sp, uint8_t *sense_data, uint32_t par_sense_len,
uint32_t sense_len, struct rsp_que *rsp, int res)
{
...
if (sense_len) {
ql_dbg(ql_dbg_io + ql_dbg_buffer, vha, 0x301c,
"Check condition Sense data, nexus%ld:%d:%llu cmd=%p.\n",
sp->vha->host_no, cp->device->id, cp->device->lun,
cp);
ql_dump_buffer(ql_dbg_io + ql_dbg_buffer, vha, 0x302b,
cp->sense_buffer, sense_len);
}
}
...https://elixir.bootlin.com/linux/latest/source/drivers/scsi/qla2xxx/qla_isr.c#L3008
...
#define ql_dbg_io 0x08000000 /* IO Tracing Debug */
...
#define ql_dbg_buffer 0x00020000 /* For dumping the buffer/regs */
...https://elixir.bootlin.com/linux/latest/source/drivers/scsi/qla2xxx/qla_dbg.h#L347
Один на 150 миллионов операций. Расследуем причины выброса времени отклика в операциях ввода-вывода