updatedb навантажував процесор: як я знайшов щоденне завдання в Ubuntu

У січні 2008 року зіткнувся з незрозумілим ранковим навантаженням в Ubuntu: раз на день запускався updatedb і займав 100% часу одного процесора. Довго не міг знайти, де вимикається цей запуск. Пошукав на форумах — і рішення виявилося дуже простим :)

Команда, яку я застосував тоді

sudo chmod -x /etc/cron.daily/slocate

Вона прибирає права виконання у конкретного сценарію /etc/cron.daily/slocate. Саму програму updatedb команда не видаляє. У моїй системі йшлося саме про цей щоденний сценарій; номер випуску Ubuntu та пакета я не занотував.

Навіщо працює updatedb

updatedb створює й оновлює базу імен файлів для locate. Якщо припинити регулярне оновлення, пошук працюватиме зі старим індексом і може не показати нові файли або показувати вже видалені.

Чому шлях завдання треба перевіряти

Спосіб запуску залежить від установленого пакета й випуску системи. У документації mlocate для Ubuntu 16.04 описано щоденний cron, а в документації plocate для Ubuntu 24.04 — systemd.timer. Отже, перед зміною налаштувань потрібно з’ясувати, яке завдання реально запускає індексацію у вашому середовищі, а не переносити старий шлях автоматично.

Оптимізація Aggregator у Drupal: досвід із базою на 200 тисяч записів

Ще раз переконався: оптимізувати доводиться не лише власне програмне забезпечення, а й сторонні системи. У січні 2008 року на моїй інсталяції Drupal модуль Aggregator почав працювати дуже повільно після накопичення приблизно 200 тисяч записів. Aggregator збирав новини з різних джерел і зберігав їх у базі. Навантаження стало помітним навіть на багатопроцесорному сервері.

Що я змінив

Під час розбору запитів у файлі \modules\aggregator\aggregator.module я прибрав використані там LEFT JOIN і додав індекси до полів, за якими виконувалося сортування. За моїм спостереженням, після цих змін затримки істотно зменшилися.

Що перевіряти разом зі швидкістю

У дописі не збережено версії Drupal, повних запитів, планів виконання чи вимірювань до й після. Видалення LEFT JOIN може змінити набір результатів, тому повторювати таке втручання без перевірки логіки не можна.

Так само індекс для кожного поля з ORDER BY не гарантує прискорення. Документація MySQL 8.4 пояснює, що використання індексу для сортування залежить від структури запиту та вартості плану. Спочатку потрібно дослідити конкретний запит і його план EXPLAIN, а після зміни перевірити і швидкість, і правильність результату.