Отправляет email-рассылки с помощью сервиса Sendsay

За 2007-01-16

Re: /var - катастрофически быстро "тает" свободное место

В сообщении от 16 января 2007 16:06 Vladimir Olegovich написал(a):
> Есть, конечно, и просто синтетические тестилки памяти. Я люблю две из них,
> но не знаю названий: одна под dos (могу глянуть название или выслать
> почтой), другая сама по себе - ее часто добавляют как бонус к разным
> дистрибутивам линукс - называется незамысловато - кажется, memtest,
> грузится, как я понял, вместо ядра ОС.

Идея хорошая, но "вместо ядра" в моем случае не подходит - я не могу надолго
останавливать сервисы... :(

Но надо будет поискать - вдруг и не надо "вместо ядра" :)

   2007-01-16 21:05:10 (#630178)

Re[2]: /var - катастрофически быстро "тает" свободное место

> > > 2. ну, или аппарат... но это уже бубны, имхо...
> > Память ?
> как проверить? :)
По идее (и по разнообразной литературе), любые глюки памяти приводят к глюкам
софта. Т.е. нужно просто взять гарантированно работающий софт, загрузить им тачку
по самую верхнюю рисочку, чтобы немного в своп вытекло и гонять. Час, два - пока
не надоест. Я для этого люблю использовать free с поднятыми x'ами, а под ними
запустить штук 20 dosbox'ов и еще столько же firefox'ов (отдельных процессов,
а не окон). Если это все не свалится за полчасика - час - вроде как машина живая.
Ну и, конечно, проверить на всякий случай БП - обычным вольтметром, а можно и
осцилографом. Под нагрузкой.

Есть, конечно, и просто синтетические тестилки памяти. Я люблю две из них, но
не знаю названий: одна под dos (могу глянуть название или выслать почтой), другая
сама по себе - ее часто добавляют как бонус к разным дистрибутивам линукс - называется
незамысловато - кажется, memtest, грузится, как я понял, вместо ядра ОС.

Но был у меня один случай, который эту всю теорию несколько опроверг: собирал
машину: какой-то третий целерон, две планки памяти, 64 Мб и стал на нее free,
тогда еще 4.9, заряжать. ОС
встала, работает, не висит, на сеть отзывается. Стал ставить на нее софт, удаленно
- вылетает при компиляции по syntax error в исходниках. Кажется, в midnight'e.
Я ее и так и этак - не хочет. В одном и том же файле одна и та же ошибка. Настолько
достоверно, что я бы поверил - если бы с этих же дистфайлов ее не ставил уже
несколько раз. Да и тест md5 же архив проходит... Стал играть памятью. Одну планку
вытащил - тот же результат. Другую вытаскиваю - опа - все работает. Ставлю назад
- не работает. Понес дохлую к техникам, которые машину собирали - они говорят
- память тестили (под виндой, с той же материнкой), все работало. Так история
и осталась загадкой. То ли битая ячейка, то ли полтергейст :) Синтетические тесты
я на этой машине, к сожалению, не гонял.

-*Название листа "[BSD] Решение вопросов по FreeBSD, OpenBSD и NetBSD";
Написать в лист: mailto:comp.soft.bsd.all-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.bsd.all/rules
Номер письма: 3108; Возраст листа: 1048; Участников: 932
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.bsd.all/msg/630174

   Vladimir Olegovich 2007-01-16 20:50:54 (#630174)

Re: /var - катастрофически быстро "тает" свободное место

В сообщении от 15 января 2007 05:58 Vladimir Olegovich написал(a):
> > 1. созданы какие-то условия для проявления ошибки в системном определении
> > свободного места
>
> Маловерятно
> Если uname -a говорит "stable"

stable

> > 2. ну, или аппарат... но это уже бубны, имхо...
>
> Память ?

как проверить? :)

>
> > в общем - что мне делать, кто скажет? :(
>
> Я бы предположил вариант проще: создается файл, открывается, затем ему
> делается unlink (т.е. удаление). Он из каталога (и, следовательно, du/mc)
> исчезает, но т.к. открыт, пространство под него остается зарезервированным.
> Узнать это можно, хотя и не совсем легко: надо сопоставить список открытых
> инодов по fstat и ls. Скриптиком. fstat также скажет - кто (pid) держатель
> такого файла.

сейчас данные для этого уже собираются, и скриптик придется писать...

> Можно просто последовательно прибивать процессы в системе и смотреть, когда
> df и du выровняются.

ok, тоже попробую :)

> А можно сделать shutdown now (т.е. перевести систему в однопользовательский
> режим (это когда кроме ядра, shell'a и init'a все выгружается) и посмотреть
> - вернется ли соответствие du и df. Только во всех случаях нужно помнить,
> что есть такая штука, как отложенная запись и она может откладываться
> секунд на 30-60 - т.е. реакция df на ситуацию в системе не моментальна.

ok, буду знать :)

   2007-01-16 11:45:27 (#630035)

Re[2]: /var - катастрофически быстро "тает" свободное место

> после reboot (только что) :
>
> df :
>
> /dev/ad0s1d 253678 14830 218554 6% /var
>
> т.е. занято теперь 14М
>
> что вполне соответствует действительности:
>
> du -d 1 /var
>
> 2 /var/.snap
> 2 /var/account
> 6 /var/at
> 22 /var/backups
> 4 /var/crash
> 420 /var/cron
> 4150 /var/db
> 2 /var/empty
> 2 /var/heimdal
> 852 /var/log
> 7882 /var/mail
> 4 /var/msgs
> 38 /var/named
> 2 /var/preserve
> 54 /var/run
> 2 /var/rwho
> 464 /var/spool
> 888 /var/tmp
> 20 /var/yp
> 2 /var/games
> 4 /var/lib
> 2 /var/irclogs
> 14826 /var
>
> со временем свободное место будет уменьшаться, а фактический суммарный размер
> файлов в /var - нет...
>
> у меня есть два варианта:
> 1. созданы какие-то условия для проявления ошибки в системном определении
> свободного места
Маловерятно
Если uname -a говорит "stable"

> 2. ну, или аппарат... но это уже бубны, имхо...
Память ?

> в общем - что мне делать, кто скажет? :(
Я бы предположил вариант проще: создается файл, открывается, затем ему делается
unlink (т.е. удаление). Он из каталога (и, следовательно, du/mc) исчезает, но
т.к. открыт, пространство под него остается зарезервированным. Узнать это можно,
хотя и не совсем легко: надо сопоставить список открытых инодов по fstat и ls.
Скриптиком. fstat также скажет - кто (pid) держатель такого файла.

Можно просто последовательно прибивать процессы в системе и смотреть, когда df
и du выровняются.

А можно сделать shutdown now (т.е. перевести систему в однопользовательский режим
(это когда кроме ядра, shell'a и init'a все выгружается) и посмотреть - вернется
ли соответствие du и df. Только во всех случаях нужно помнить, что есть такая
штука, как отложенная запись и она может откладываться секунд на 30-60 - т.е.
реакция df на ситуацию в системе не моментальна.

-*Название листа "[BSD] Решение вопросов по FreeBSD, OpenBSD и NetBSD";
Написать в лист: mailto:comp.soft.bsd.all-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.bsd.all/rules
Номер письма: 3106; Возраст листа: 1048; Участников: 931
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.bsd.all/msg/629886

   Vladimir Olegovich 2007-01-16 00:07:57 (#629886)