Размер ../logfiles/users/ FET 4.0.*

Фет это чудо скрипт конечно. но уже месяца 4 (примерно столько его юзаю) меня достаёт занимаемый размер директории для лог файлов.
/home/............../logfiles/users/
Там создаётся умопомрачительное количество директорий.
Может у меня руки такие кривые и в итоге размер той директории меньше 500Мб (с учётом остатков клайстеров) небывает. Вообщем позаменял я все (кроме двух) CJ на другие. В итоге скучаю страшно так как ничего более хорошего (из общедоступных) я ещё не видел.
Осталось два сиджа с FET 4.0.5 на данный момент тоже наверное придётся менять если кто нибудь не скажет как вылечить большой объём директории лог файлов.
Сейчас например обьём одного сиджа (директории лог файлов) более 800 Мб при том что траффика не более 35К
На другом практически такая же фигня.

Спасите FET уважаемые AWM(ы)!

Пользователям fet 4.0.* :
КАКОЙ ОБЬЁМ дирекрии лог файлов у вас ?

Фет не юзаю, но самое тупое решение которое приходит в голову - засунь в крон скрипт удаления лишних файлов раз в час или сколько там нужно...

а у тебя скрипт очистки в кроне прописан нормально?
работает ли он, проверь

81kb, 2к файлов, чищу раз в час
посмотри, у них на сайте есть пример такого скрипта.

Как оказалось я был не далек от истины...

Кстати, как бывший программист совершенно не понимаю, нахуя сиджевому скрипту создавать много файлов...

Phoenix66 писал:

Кстати, как бывший программист совершенно не понимаю, нахуя сиджевому скрипту создавать много файлов...

Вероятность падения базы меньше

von Stoltz писал:

Вероятность падения базы меньше

Это каким же боком? Ну и даже если так - почему нельзя удалять временные файлы на автомате?

Насколько я понимаю фет вообще сишный скрипт, хранящий базу в памяти. Достаточно раз в час сбрасывать данные в файл. Для сиджа потеря данных за час не критична ни коим образом, особенно учитывая что нормально настроенный сервер легко работает 200+ дней без перезагрузки.

Впрочем, возможно я чего-то не понимаю.

Этот размер - плата за скорость и неиспользование базы данных.
Насколько представляю принцип фета, данные каждого ип хранятся в отдельном файле, в результате чего 1 уник == 4 кб места.
А так как нормальный сидж уника считает за сутки, т.е. каждый файл должен лежать сутки.
Вот и считай, 1к. уников == 4 мега места.

Естественно можно использовать свою бинарную базу или память, но тут нужны другие знания и возможности. Та же работа пхп с шареной памятью как правило везде выключена.

Вобщем тут куча проблем. Так что если жалко места, либо сиджи с mysql либо те, которые используют собственные базы, а не файловую систему в качестве базы.

Aleksey+ писал:

Фет это чудо скрипт конечно. но уже месяца 4 (примерно столько его юзаю) меня достаёт занимаемый размер директории для лог файлов. /home/............../logfiles/users/ Там создаётся умопомрачительное количество директорий. Может у меня руки такие кривые и в итоге размер той директории меньше 500Мб (с учётом остатков клайстеров) небывает. Вообщем позаменял я все (кроме двух) CJ на другие. В итоге скучаю страшно так как ничего более хорошего (из общедоступных) я ещё не видел. Осталось два сиджа с FET 4.0.5 на данный момент тоже наверное придётся менять если кто нибудь не скажет как вылечить большой объём директории лог файлов. Сейчас например обьём одного сиджа (директории лог файлов) более 800 Мб при том что траффика не более 35К На другом практически такая же фигня. Спасите FET уважаемые AWM(ы)! Пользователям fet 4.0.* : КАКОЙ ОБЬЁМ дирекрии лог файлов у вас ?

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

$ du -s users
1416412 users

Сидж 25k

Phoenix66 писал:

Фет не юзаю, но самое тупое решение которое приходит в голову - засунь в крон скрипт удаления лишних файлов раз в час или сколько там нужно...

Есть такой скрипт стандартный и он выполняется, но удаляет файлы а директории остаются. И их там мягко сказать дохерища.

Blazer писал:

а у тебя скрипт очистки в кроне прописан нормально? работает ли он, проверь

Прописано правильно. Файлов старше (дата создания) 25 часов не обнаружено.

belamor писал:

81kb, 2к файлов, чищу раз в час посмотри, у них на сайте есть пример такого скрипта.

Как ты это делаешь без потери всей статистики ?

Phoenix66 писал:

Это каким же боком? Ну и даже если так - почему нельзя удалять временные файлы на автомате? Насколько я понимаю фет вообще сишный скрипт, хранящий базу в памяти. Достаточно раз в час сбрасывать данные в файл. Для сиджа потеря данных за час не критична ни коим образом, особенно учитывая что нормально настроенный сервер легко работает 200+ дней без перезагрузки. Впрочем, возможно я чего-то не понимаю.

Cкрипта данных версий состоит из PHP закодированной Зендом и CGI на Perl.

jAPAN писал:

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

На Линуксе у меня всё. Скрипт со своей функцией справляется.

ghood писал:

$ du -s users 1416412 users Сидж 25k

Я так понял это в байтах.
Мне бы такой обьём. В чём секрет раскажи пожалуйста ?

Попробую по-другому

Цитата:

du -h -s logfiles/users/ 1.4G logfiles/users

Aleksey+ писал:

Cкрипта данных версий состоит из PHP закодированной Зендом и CGI на Perl.

Тогда ясно...


2 Stek - мои познания Линукс систем находятся в зачаточном состоянии, но чисто по аналогии, исходя из знания системотехники - разве нельзя повесить демон написанный на чистом си, который бы выполнял функции mysql с той разницей, что был бы заточен конкретно под скрипты сиджа? Естественно я не имею в виду что он должен эмулировать MySQL, просто через сокс или что там в линуксе еще есть обрабатывал бы запросы из php, вроде php умеет пихать данные таким образом в стандартной конфигурации, без всяких дополнительных настроек. Ну а демон бы уже работал с памятью, по необходимости сбрасывая на диск.

Aleksey+ писал:

Есть такой скрипт стандартный и он выполняется, но удаляет файлы а директории остаются. И их там мягко сказать дохерища.

это сделано для того, чтобы потом не было накладных расходов на создание снова этих директорий.

Aleksey+ писал:

Как ты это делаешь без потери всей статистики ?

обрати внимание, что то дерево файлов, о котором ты говоришь это хранение кук. к статистике это дело не имеет отношения. если тебя смущает размер директории, можно уменьшить время хранения кук.

Aleksey+ писал:

На Линуксе у меня всё. Скрипт со своей функцией справляется.

хм. я не могу утверждать точно в чем у тебя проблема не видя конкретные условия, если нужно выправить ситуацию - постучись ICQ ******

Phoenix66 писал:

Тогда ясно... 2 Stek - мои познания Линукс систем находятся в зачаточном состоянии, но чисто по аналогии, исходя из знания системотехники - разве нельзя повесить демон написанный на чистом си, который бы выполнял функции mysql с той разницей, что был бы заточен конкретно под скрипты сиджа? Естественно я не имею в виду что он должен эмулировать MySQL, просто через сокс или что там в линуксе еще есть обрабатывал бы запросы из php, вроде php умеет пихать данные таким образом в стандартной конфигурации, без всяких дополнительных настроек. Ну а демон бы уже работал с памятью, по необходимости сбрасывая на диск.

не хочу сползать в оффтопик, но все-таки хочется сказать немного по этому поводу. дело в том, что написание такого демона на Си - очень профессиональная задачка и меня берут большие сомнения, что такой демон будет быстрее работать, чем тот же мускуль на файловой системе. маленькая подсказка для интересующихся вопросом - у мускуля есть heap таблицы, о которых почему-то часто забывают =) учитывая то, как долго затачивали мускуль для работы в многопоточном режиме - вряд ли его переплюнет разработка сишной программы для сиджея.

jAPAN писал:

не хочу сползать в оффтопик, но все-таки хочется сказать немного по этому поводу. дело в том, что написание такого демона на Си - очень профессиональная задачка и меня берут большие сомнения, что такой демон будет быстрее работать, чем тот же мускуль на файловой системе. маленькая подсказка для интересующихся вопросом - у мускуля есть heap таблицы, о которых почему-то часто забывают =) учитывая то, как долго затачивали мускуль для работы в многопоточном режиме - вряд ли его переплюнет разработка сишной программы для сиджея.

jAPAN - если бы я знал матчасть, ну максимум за неделю бы написал. Это не понты, просто из опыта сужу по сравнению с тем что я за месяц умудрялся делать на тех системах которые хорошо знал. Но к сожалению я не знаю Линукс и не знаю с какого конца подходить к изучению. Это надо на машину линукс ставить, ебаться опять с примитивами... мне это так надоело еще 5 лет назад. Я тут сраный MySQL полгода не мог себя заставить изучить, но пришлось таки в итоге.

Любая УЗКО специализированная ГРАМОТНО написанная прога для работы с ГРАМОТНО заточенной под данный узкий случай базой быстрее универсального движка, как бы хорошо он не был оптимизирован. Причем разница может быть в сотни раз, а не в доли процента.

И ты забываешь один важный момент - всю математику можно тоже запихать в си, из php только данные пихать и результат готовый получать, что уже должно дать огромный эффект по быстродействию.

Phoenix66 писал:

jAPAN - если бы я знал матчасть, ну максимум за неделю бы написал. Это не понты, просто из опыта сужу по сравнению с тем что я за месяц умудрялся делать на тех системах которые хорошо знал. Но к сожалению я не знаю Линукс и не знаю с какого конца подходить к изучению. Это надо на машину линукс ставить, ебаться опять с примитивами... мне это так надоело еще 5 лет назад. Я тут сраный MySQL полгода не мог себя заставить изучить, но пришлось таки в итоге. Любая УЗКО специализированная ГРАМОТНО написанная прога для работы с ГРАМОТНО заточенной под данный узкий случай базой быстрее универсального движка, как бы хорошо он не был оптимизирован. Причем разница может быть в сотни раз, а не в доли процента. И ты забываешь один важный момент - всю математику можно тоже запихать в си, из php только данные пихать и результат готовый получать, что уже должно дать огромный эффект по быстродействию.

хочу охладить ваш пыл =) дело в том, что немногие из присутствующих на форуме программистов написали бы сишный код, который выполнял бы узкоспециализированные задачи быстрее мускуля. а те, кто мог бы написать - взяли бы за это цену, как за шаттл =) о чем я вообще веду речь - я хочу объяснить что не всегда выигрыш в таких мелочах стоит затрат на разработку, гораздо более полезнее оптимизировать работу существующих инструментов (мускуль с хеап таблицами, работа с файловой системой), чем замахиваться на эдакую стройку мега-велосипеда.

Поддерживаю jAPAN.
Да безусловно возможно написать многопоточного демона, заточенного под нужды конкретного сиджа, но это даст не очень большой прирост производительности и достаточно большие затраты. Всё равно MySQL большую часть при очень большой нагрузке проводит в syscalls, поэтому я не думаю что это хорошая идея (данные цифрами не подтверждены ). Это вроде стрельбы из пушки по воробьям.
Кстати хttp://slashdot.org держится на perl + MySQL, так что может старик мускуль держать достаточно большую нагрузку (имхо намного бОльшую чем большинство сиджей ).
Кстати я бы взялся реализовывать данную задачу только при наличии большого количества времени и хорошей оплате
Но это по оффтопику.

А по топику,
у меня не работал скрипт очистки. Пришлось править


P.S. Опыт программирования Linux 5 лет

Я кстати ничего против MySQL не имею, ибо после некоторых экспериментов выяснилось, что он то как раз меньше всего грузит систему, если сидж правильно написан. Вопрос именно в выносе всего остального из php в бинарник.

Насчет того что "дорого и сложно" все же повторю, что нифига сложного там нет. Больше думать придется о правильной организации чем непосредственно писать. Реально написание интерфейсов по жизни больше отнимает времени чем написание матаппарата.

Проблема временно самоустранилась.

Снёс я этот FET 404 и поставил 405 (хотел 406 да перепутал).
Файл (cleaner.sh) отвечающий за удаление лог файлов там был такой же что и у меня стоял.
Жуткая наверное картина была дял дрона при переустановке без блокировки сайта. Но пришлось на это пойти.

Осталось только ждать не повысится ли размер как был.