Удалить овер дохрена файлов в одной директории

МЕНЕЕ оптимален

Ещё один :(.

Просто переопределил место хранения сессионных файлов и все. А гц по крону только в тмп ходит, т.е. только в стандартное место.

понятно.. спасиб за пояснение :-) ..

в PHP есть свой собственный механизм, который удаляет мусорные данные, независимо от того какой каталог определён. (и поумолчанию этот механизм НЕ выключен).

но — да — в некоторых операционных системах есть ещё и задание крона которое удаляет сессионные файлы — но это нестандартный костыль. [хотя соглашусь что этот костыль может увеличить скорость].

скажу сразу, что лично я имею резко-негативное мнение по отношению к этому крон-костылю — так как он хорошо работает только для одного определённого сценария-использования. а для остальных сценариев-использования — этот костыль является обузой :-( ..

btrfs+lzo+отельный раздел под мусор, и крон вполне рабочее решение.

> МЕНЕЕ оптимален

Ещё один :(.

ну уж прости, вот так!

но оскорблять тебя я не буду, я не такой :-)

Спасибо!

этот механизм НЕ выключен

Дистр, версия пыхпыха, опция в конфиге?

btrfs+lzo+отельный раздел под мусор

это хорошо.. щаз btrfs вполне хорошо работает с мелкими файлами.. они занимают кучу места, но место же дешёвое (жёсткие диски больше).

и крон вполне рабочее решение.

рабочее конечно :-) [и я даже написал, что оно более быстрое.. разве не написал?] ..

но страдает гибкость, так как:

1. крон это НЕ портативное решение. плохо пригодно в ситуации когда тебе нужно поддерживать работу кучи web-сайтов на одном сервере. и когда нужно несколько web-сайтов перемещать на другие сервера (с другой организацией).

2. в зависимости от вида web-сайта — требуются разные настройки времени-устаревания сессионных файлов. а вшивать это значение намертно внутрь крон-задачи помоему как-то неочень круто :-)

то есть, что я имею ввиду.

когда у тебя 1-сервер это 1-web-сайт (и больше других web-сайтов у тебя нет) — то вот в этом случае крон-задача это вполне сносное решение..

интересно было бы глянуть на этот PHP-код :) ..

там архитекутра портала - адЪ и страдания

ведь он сделал это с каким-то умыслом? o_0

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

А с другой стороны хорошо, что падает уровень грамотности разработчиков - больше халтуры =)

обычное явление, потому что у вас дебильный договор, вот чистили бы за 10000+ за 1 раз, было бы по другому.

> этот механизм НЕ выключен

Дистр, версия пыхпыха, опция в конфиге?

вот тебе ссылка (я её уже публиковал в этой теме.. но ничего страшного пусть ещё раз будет!)

http://php.net/manual/en/session.configuration.php

в этой ссылке написаны какие настройки PHP являются настройками поумолчанию.

если в каком-то дистрибутиви отключили сборку мусорных сессионных файлов — то это просто повод для тикета (в багтрекер дистрибутива).

и да — вполне типичная настройка Apache-сервера для PHP — это, как мне кажется, использование ``mod_fcgid`` ..

...и в этом случае внутри ``php-wrapper`` задаётся каталог откуда читать ini-файл для php .

а если у него ngix+phpfmp?

а если у него ngix+phpfmp?

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

а официальная документация явно гласит что эта настройка включена по-умолчанию. так что тот кто отключил — тот и дурак :-D .. вот идите и ищите его :-)

хотя если именно я занимаю тем что меняю session-настройки.. ..то обычно я меняю их все (и НЕ надеюсь на что-то там есть где-то поумолчанию). или лучше их вообще тогда не менять :-)

А с другой стороны хорошо, что падает уровень грамотности разработчиков - больше халтуры =)

ды халтуры и так полно.. уж лучше бы уровень не падал бы :-)

обычное явление, потому что у вас дебильный договор, вот чистили бы за 10000+ за 1 раз, было бы по другому.

Ага, по-другому. Чистил бы кто-то другой.

leave пока не будет извинений от post-factum так просто это не закончится. Мне не сложно, а открытых прокси навалом.

Как вариант, это мог быть дебиан/убунта, в котором gc отключен в глобальном php.ini (probability=0), и вместо него запилен кронджоб, который чистит /var/lib/php5/. Соответственно, если разработчик/деплоер не в курсе этого поведения, а сессии хотят хранить «у себя» (рядом с кодом) - проблемы обеспечены.

извинений от post-factum

Ты кто такой вообще?

leave, извини за беспокойство.

sdio, угомонись. Два взрослых человека, а ведете себя, как дети.

А ты? Хамишь без остановки и еще в претензиях.

Я уже сказал, когда это закончится.

sdio??? Но он же был нормальным!

В тебе дело, не хами и извинись.

Гуляй.

Ты себя тоже не с лучшей стороны показываешь. Боксеры по переписке, блин.

ОК, умолкаю.

Я бы попробовал

find dir -type f -exec rm {} \; && find -d dir -type d -exec rmdir {} \;

Тогда уж find dir -depth -type d -exec rmdir {} \;, а то на выходе получится куча вложенных пустых каталогов.

-d вроде и есть -depth.

Согласен, но тогда не '-d dir', а 'dir -d'.

Это я из BSD-шного мануала вычитал:

find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]

в GNU-том да, надо так.