https://www.opennet.me/openforum/vsluhforumID3/12597.html Игорь Сысоев оформил в виде патча (http://www.sysoev.ru/freebsd/softupdates.html) исправление неприятной и существующей непонятно сколько времени ошибки в FreeBSD softupdates, проявляющейся в том, что в один прекрасный момент свободное дисковое пространство начинало катастрофически уменьшаться пока не доходило до нуля. Помогала только перезагрузка.<br><br><br>В FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправление ошибки появилось в конце августа.<br><br>URL: http://www.sysoev.ru/freebsd/softupdates.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=6327<br> https://www.opennet.me/openforum/vsluhforumID3/12597.html#40 Mon, 31 Oct 2005 17:43:58 GMT &gt;А что интересно так это по какому принципу разделы freebsd уходят в <br>&gt;минуса? :) Тоесть бывало видел в /tmp свободно -10% )) <br><br>man tunefs /-m<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/12597.html#39 Mon, 31 Oct 2005 13:41:15 GMT &gt;В UFS при создании резервируется место (точно не помню сколько именно, может <br>&gt;как раз эти 10%) "для рута". Остальное место считается полным размером <br>&gt;ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. <br>&gt;И никто кроме рута тогда не может писать на этот раздел. <br>&gt;(Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество <br>&gt;есть). <br><br>Для справки. Это место резервируется не для root'а, а для служебных нужд файловой системы. Файловая система при наличии этого свободного места более оптимально распределяет свободные блоки, в результате чего сводится к минимуму фрагментация файлов. Установка этого параметра менее 5% отключает алгоритм оптимизации, в результате чего вы полусаете больший процен фрагментации =&gt; снижение скорости. https://www.opennet.me/openforum/vsluhforumID3/12597.html#38 Sat, 29 Oct 2005 18:31:17 GMT если включть query_cache_type=1, то до тех пор, пока не исчерпается query_cache_size=xxx повторные запросы (те, что уже попали в кэш) не создают временных файлов. Но в первый раз на любой запрос временный файл на диске все равно создается! https://www.opennet.me/openforum/vsluhforumID3/12597.html#37 Sat, 29 Oct 2005 18:15:11 GMT &gt;правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь <br>&gt;потом стереть - потери места не наблюдается. <br><br>Наблюдается. Вы не о той потере места говорите. Не путайте тривиальное незакрытие файла после unlink'а, которое сразу видно в fstat, и проблему softupdates, для которой и выпущен данный патч и которая странным и трудноповторимым образом проявлялась, раз в полгода, на серверах интенсивно оперирующих большими файлами.<br><br> https://www.opennet.me/openforum/vsluhforumID3/12597.html#35 Sat, 29 Oct 2005 18:02:50 GMT &gt;У меня такое было когда MySQL был сильно нагружен, загрузка процессора была <br>&gt;долгое время 100%. Когда пересмотрел задачу и снизил число запросов - <br>&gt;место перестало исчезать <br><br>Речь идет о ситуации когда после того как руками создал файл и удалил его, число свободныех инод не увеличивается (после истечения metadelay и sync;sleep 1;sync;sleep 1;sync;sleep 1;sync). И так для каждого удаления, пока места или инод не останется.<br> https://www.opennet.me/openforum/vsluhforumID3/12597.html#34 Sat, 29 Oct 2005 17:07:44 GMT по пробуйте покрутить tmp_table_size https://www.opennet.me/openforum/vsluhforumID3/12597.html#33 Sat, 29 Oct 2005 14:55:13 GMT А тем временем в RELENG_6_0 прошёл не хилый такой MFC связанный с ffs и vfs:<br>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1114104+0+current/cvs-src#content https://www.opennet.me/openforum/vsluhforumID3/12597.html#32 Sat, 29 Oct 2005 13:30:10 GMT У меня такое было когда MySQL был сильно нагружен, загрузка процессора была долгое время 100%. Когда пересмотрел задачу и снизил число запросов - место перестало исчезать https://www.opennet.me/openforum/vsluhforumID3/12597.html#31 Sat, 29 Oct 2005 10:19:11 GMT Посмотрим. Условия в которых оно вешается, примерно известны.<br>Когда в заросе есть JOIN mySQL пишет временную таблицу строго на диск.<br>Заставить mySQL не писать JOIN в /tmp не сумел.<br>Сильно похоже на потерю нодов софтапдейтом.<br>Если за следующую неделю сервис снова висанёт, значит софтапдейтс не при чем.