Кейс
Почему главный список внезапно перестаёт открываться
Главный список клиента перестал открываться, хотя все остальные страницы работали. Причина была в одной записи, намного большей, чем остальные, и та же ошибка тихо срабатывала в фоновой задаче.
Главное
- За списком, который внезапно перестал открываться, часто стоит одна слишком большая запись, а не чьё-то изменение.
- База данных сортирует строки целиком, поэтому одна запись больше отведённой для сортировки памяти проваливает всю страницу.
- Список должен загружать только то, что показывает; длинные документы и файлы относятся к странице, которая открывает одну запись.
- Та же причина часто тихо сбоит в фоновой задаче по расписанию, о которой никого не предупреждают.
- Поднятие лимита памяти переносит проблему на следующую, ещё большую запись, а не убирает её.
Команда клиента открыла главный список во внутренней системе, а страница показала ошибку. Этот экран никто не менял, и все остальные страницы работали. Причина была в одной записи, которая выросла намного больше остальных.
Чего стоит команде список, который не открывается
В главном списке команда находит, открывает и завершает свою работу, поэтому когда он перестаёт открываться, вместе с ним останавливается вся команда. У этого клиента в списке лежат записи, с которыми работает команда, новые сверху. Страница, которой пользовались не задумываясь, теперь показывала только ошибку, а все остальные экраны вели себя как обычно.
Именно это сочетание, один сломанный экран и ничего не изменённого, и делает такие сбои загадочными. По нашему опыту они возвращаются, потому что сбой растёт вместе с данными, а не с тем, что сделал человек. Тот же симптом встречается в любой растущей системе: сломался список во внутреннем инструменте, не открывается список в CRM, не работает экран, на который команда опирается весь день.
Почему страница списка не загружается: часто всё дело в одной большой записи
Чтобы показать новые записи первыми, база данных сортирует строки, и сортирует их целиком. База данных — это хранилище, где внутренняя система держит свои записи, и сортировка происходит каждый раз, когда вы запрашиваете записи в определённом порядке. Для такой сортировки база данных выделяет фиксированный объём памяти как рабочее пространство и не взвешивает каждую строку перед началом: каждая строка попадает в сортировку полностью, со всем, что в ней есть. Одна строка больше этого объёма проваливает весь список, какими бы маленькими ни были остальные.
Вот почему рост размера записей ломает всё так же верно, как и рост их числа. Добавление записей замедляет список; добавление одной необычно большой записи может вообще не дать ему открыться.
Что нашёл наш инженер
Ошибка пришла из базы данных и сообщала, что ей не хватило памяти для сортировки. Поскольку новые записи показывались первыми, строки сортировались, и каждая строка несла тяжёлое поле вместе с заголовком и датой. Это поле было длинным блоком текста, который список никогда не показывал.
Обычно такие поля небольшие. Команда недавно начала создавать новый вид записей, и одна из них несла поле намного длиннее, чем всё, что было раньше. База данных выделяет фиксированный объём рабочей памяти для такой сортировки, и эта одна строка в него больше не помещалась, поэтому весь список падал. Увеличение памяти базы данных только сдвинуло бы предел до следующей, ещё большей записи.
Переломным моментом стал простой вопрос: нужно ли списку это поле вообще? Он показывает заголовок, состояние и дату, и ничего больше.
Поиск той же ошибки в других местах рассказал остальное. Та же ошибка тихо срабатывала в фоновой задаче, работе, которая запускается по таймеру, когда за ней никто не следит. Никто её не видел. Команда знала только об экране перед собой.
Что мы изменили
Мы сделали так, что список читает каждую запись без тяжёлого поля, поэтому страница загружает только заголовок, состояние и дату. Поле читается, когда кто-то открывает эту запись, и только тогда. Мы также добавили индекс, структуру поиска, которая держит записи в порядке их последнего изменения, так что показ последних первыми вообще не требует сортировки.
Вскоре тот же подход охватил всю систему: если не запрошены конкретные поля, запрос этих записей теперь по умолчанию оставляет тяжёлое поле в стороне, включая запросы фоновой задачи. Открытие одной записи по-прежнему читает поле полностью. Новая автоматическая проверка теперь ловит это, если список или задача снова начнут запрашивать поле.
Что теперь есть у бизнеса
Изменения заработали в системе клиента в тот же день. Список снова открывается, и фоновая задача снова выполняется. Запись любой длины больше не может сломать ни то, ни другое, а открытие одной записи работает как раньше.
Что вы можете проверить сами
- Спросите своего разработчика, что ваша самая загруженная страница списка загружает для каждой строки и не загружает ли она то, что экран никогда не показывает.
- Спросите, сообщают ли кому-нибудь, когда фоновая задача падает, и как вы узнали бы сегодня, что какая-то из них давно тихо сбоит.
- Если кто-то предлагает поднять лимит памяти, чтобы ошибка исчезла, сначала спросите, что экрану на самом деле нужно; более высокий лимит только ждёт следующей, ещё большей записи.
- Когда вы начинаете в своей системе новый вид работы, например с намного более длинными документами или файлами, спросите, не может ли какой-нибудь экран задохнуться от размера одной записи.
- Не останавливайтесь на экране, на который пожаловались. Спросите, нет ли той же ошибки в задачах, на которые никто не смотрит.
Что делать дальше
Возьмите список, которым ваша команда пользуется чаще всего, и задайте вопрос, который открыл этот случай: что этому экрану нужно для каждой строки и что он загружает всё равно. Затем попросите способ узнавать, когда фоновая задача падает, а не узнавать об этом по сломанному экрану. Проследить такой сбой до его причины — это та работа, которую наши инженеры делают для клиентов, и обычно она начинается с одного простого вопроса о том, что страница на самом деле запрашивает.
Частые вопросы
Как узнать, что фоновая задача давно тихо сбоит?
Спросите того, кто отвечает за вашу систему, записываются ли где-нибудь сбои задач по расписанию и предупреждают ли об этом кого-нибудь. Если ответ такой, что никто не узнает, это стоит исправить в первую очередь, потому что сбойная задача не даёт видимых симптомов, пока кто-то не начнёт зависеть от результата.
Почему наш экран списка сломался, хотя никто ничего не менял?
Потому что изменились данные, а не экран. Список, который сортирует свои строки, заставляет базу данных держать каждую строку в рабочей памяти, и одной записи, выросшей за пределы отведённого места, достаточно, чтобы страница остановилась. Сам экран может оставаться нетронутым долгое время, прежде чем это случится.
Как одна запись может не дать загрузиться целой странице?
База данных сортирует все строки вместе и не пропускает большие части записи во время сортировки. Если одна строка больше памяти, отведённой для этой сортировки, вся операция падает, и странице нечего показать. То, что остальные записи маленькие, не помогает.
Может, просто увеличить лимит памяти базы данных?
Поднятие лимита может убрать ошибку сейчас, но оно не отвечает на вопрос, почему страница загружала так много. Следующая более длинная запись может перейти новый лимит, и тот же сбой вернётся. Лучше спросить, что экрану на самом деле нужно, и загружать только это.
Что должен загружать экран списка для каждой строки?
Список должен загружать только те поля, которые показывает, например заголовок, состояние и дату. Длинный текст, файлы или детали производства относятся к странице, которая открывает одну запись. Это держит список быстрым и не даёт одной большой записи его сломать.