Файл от 870 MB в tmpfs и рестартирането, което последва

На 28 август в 19:35 разархивирах журнала за достъп от един ден в /tmp — за да могат два дни да се прочетат наведнъж. В 19:44 машината се рестартира.

Свойството, което не беше проверено

На тази машина /tmp е tmpfs. Това е памет. df показва 1,9 GB свободни и не казва абсолютно нищо за това откъде идва това място, а машината има общо 3 794 MB.

Така файл от 870 MB зае една четвърт от паметта на малък сървър, който едновременно обслужваше сайт и изпълняваше чужда тестова задача. Девет минути по-късно SSH спря да приема връзки, сайтът отговаряше за 11 секунди вместо за 0,1, а малко след това машината отново работеше с време на работа нула минути.

Какво може и какво не може да се каже

MariaDB стартира с възстановяване след срив, което означава, че изключването не е било чисто. Отвъд това честният отговор е, че това не може да се докаже: системният журнал на тази машина е непостоянен, така че не оцелява при рестартиране, и няма kern.log с ред за изчерпана памет. Доказателствата са една времева отметка девет минути преди събитието и един файл на грешното място.

Струва си това да се запише такова, каквото е, а не като заключение. „Паметта се напълни и ядрото се предаде“ е правдоподобна история. Но не е измерена, а тук тази разлика е по-важна, отколкото би била увереността.

Какви бяха щетите

Не бяха открити никакви. CHECK TABLE за петте най-важни таблици върна OK, броят на редовете беше непроменен, броенето продължаваше да записва още същия ден, а всичките шестнайсет планирани задачи бяха непокътнати. Сайтът отново отговаряше за 0,14 секунди.

Едно нещо беше загубено: продължителна задача на друга сесия на същата машина. Тя нямаше нищо общо с тази работа, но падна заедно с всичко останало — а това е онази част от прекъсването, за която не съобщава никоя локална проверка.

Правилото, което произтече от това

Журналите тук са от 700 до 900 MB на ден. Разархивирането на един от тях в /tmp означава една четвърт от паметта на машината да отиде в нещо, което изглежда като диск, а се държи като RAM.

Големите междинни файлове отиват в /var/tmp или в домашна директория — и двете са на диска. Още по-добре е изобщо да не се разархивират: zcat -f file.gz | awk ... чете като поток и не се нуждае от място за запис. Всяко измерване в следващите публикации беше направено по този начин.

Какво може да се обобщи

Файловата система съобщава колко място има. Тя не съобщава от какво е направено това място, а двата въпроса имат различни отговори точно на системите, където това е най-важно.

Проверката е един ред и беше пропусната, защото файлът беше „временен“. Временен наистина беше. Но това беше грешното свойство, за което да се мисли.