03:00. Разбираем сценарий: K3s с SQLite, после роста частоты обновлений объектов растёт задержка API. CPU свободен, средний поток записи невелик. Поверхностный диагноз — «тормозит API, добавим ресурсов». Но запросы к хранилищу идут через Kine, а SQLite допускает только одного писателя одновременно. Это граница конкурентной записи, а не приговор SQLite. Основа схемы: K3s datastore. В WAL запись журнала и checkpoint — разные операции. При synchronous=FULL журнал синхронизируется при каждом коммите; при NORMAL синхронизация связана с checkpoint. Долгая читающая транзакция может мешать завершению checkpoint, но один размер WAL ещё не доказывает причину задержки. Нельзя приписывать K3s настройки из случайной sqlite3-сессии: synchronous задаётся для соединения. Механика: SQLite WAL. Проверяем гипотезу: iostat -xz 1 показывает w_await и aqu-sz; cat /proc/pressure/io — долю времени ожидания I/O через some/full. Короткий захват sudo timeout 15s strace -f -T -e trace=fsync,fdatasync -p $(pidof k3s) позволяет увидеть длительность синхронизаций; сам strace добавляет накладные расходы. Сопоставляем их с p99 изменяющих API-запросов. Длинный fdatasync подтверждает ожидание синхронизации, но ещё не отличает конкуренцию за диск от задержек самого накопителя. Исправление выбираем по уликам: убираем лишние обновления объектов, проверяем соседнюю дисковую нагрузку и задержки flush. При подтверждённом пределе записи или требовании нескольких server-узлов планируем смену datastore. Etcd тоже платит за устойчивую запись. Отключать синхронизацию ради зелёного графика — прятать риск потери подтверждённых изменений до следующего отключения питания. https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=sqlite-wal-rezhim-v-k3s-control-plan
