Аномальное поведение одной директории

VPS под OpenVZ
Как такое может быть?

Overselling over 9000. Наделали стопицот контейнеров, а iops'ов на всех не хватило.

Overselling over 9000. Наделали стопицот контейнеров, а iops'ов на всех не хватило.

Думал об этом, но почему просто ls в директории из 32х директорий так себя ведёт? Почему блокируется доступ к файлам, расположенным в директориях, расположенных в этой директории? При этом с файлами, расположенными в других местах диска, проблем нет: на сайте в этот момент всё работает без тормозов, где не используется доступ к сессиям, БД работает ОК, а вот там где используется сессия, то всё зависает в ожидании когда отпустит ls. Странная фигня какая-то.

Что за файловая система? ls -ld . в этой директории что показывает?

«iotop показывает загруженность IO процессом ls на 99% и скорость чтения _несколько МБ/с_»
Не похоже на нехватку иопсов

А размер каталога какой? В смысле не сумма размеров файлов, а именно каталога (который в каком-то смысле тоже файл со списком файлов).

Похоже на фрагментацию каталогов.

Что за файловая система?

ext4

Примонтировано так:
/dev/ploop12345p1 on / type ext4 (rw,relatime,barrier=1,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)

ls -ld . в этой директории что показывает?

drwxrws--- 34 www-data www-data 309M Янв 12 19:58 /var/lib/php5/sessions

Похоже на фрагментацию каталогов.

Как это? Каталоги были сгенерированы скриптом разово два года назад, а файлы сессий старше суток внутри удаляются по крону раз в сутки ночью (с помощью find -delete, тоже так же очень медленно).

Ну ок, если допустить что файлы разбросаны по диску далеко друг от друга, то почему ls тормозит, где лежать только каталоги, которые были созданы за раз и там не должно быть фрагментации по идее.

Ну ок, если допустить что файлы разбросаны по диску далеко друг от друга, то почему ls тормозит, где лежать только каталоги, которые были созданы за раз и там не должно быть фрагментации по идее.

До файлов дело ещё не дошло. их там у тебя

примерно по 20-30 файлов

Пока говорим о каталоге. Суть в том, что при удалении файла вот так

а файлы сессий старше суток внутри удаляются по крону раз в сутки

файл в каталоге просто помечается как удалённый.

Теперь представь, что происходит при каждом обращении по пути. А если каталог занимает сотни метров?

309M

Вот это — размер директории. Не файлов в ней, а просто структур на диске, в которых хранится список файлов и директорий в ней.

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

Я знаю про два варианта решения. Первый это проверить раздел с помощью e2fsck, добавив в ключи -D. Второй — создать рядом новую директорию, перенести в неё содержимое sessions, потом sessions удалить, а новую директорию переименовать в sessions. Оба варианта требуют так или иначе сервер на время выключить.

Первый это проверить раздел с помощью e2fsck, добавив в ключи -D

Не прокатит скорей всего, openvz же, я даже своп-файл добавить не могу с помощью swapon.

Второй — создать рядом новую директорию, перенести в неё содержимое sessions, потом sessions удалить, а новую директорию переименовать в sessions.

Да, была такая идея, но это ведь придётся периодически повторять.

Я думаю лучше разбить очистку сессий на подкаталоги так:

DIRS='0 1 2 3 4 5 ... a b c и т д'

for SUBDIR in $DIRS
  do
    find "/var/lib/php5/sessions/$SUBDIR" -type f -mtime +1 -delete
done

Должно быстро работать.

Спасибо за разъяснение.

но это ведь придётся периодически повторять.

Сомневаюсь. Судя по описанному сценарию работы в /var/lib/php5/sessions не создаются и не удаляются файлы. Скорее всего, в какой-то момент в прошлом все сессии писались туда плоским списком, из-за чего директорию и раздуло.

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

Скорей всего, т.к. по дефолту у PHP так и есть.

Кстати, а зачем сервер останавливать для пересоздания директории? Вроде если просто сделать однострочником cp -a sessions sessions2; rm -rf sessions; mv sessions2 sessions проблем быть не должно.

Что за файловая система?

ext4

Это постоянное больное место ext4 :-/

Оба варианта требуют так или иначе сервер на время выключить.

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

создать рядом новую директорию, перенести в неё содержимое sessions, потом sessions удалить, а новую директорию переименовать в sessions. Оба варианта требуют так или иначе сервер на время выключить.

Чой-та? Уже открытые файлы открыты и никуда не денутся от удаления каталогов. Операция переименования вроде атомарна. Проще создать рядом каталог и переименовать его в sessions. Открытые файлы удалятся после закрытия. И никаких перезагрузок/остановок - ты что, вендузятнег штоле?

Хотя всё зависит от поведения mv/rename

Да, была такая идея, но это ведь придётся периодически повторять.

Это и есть решение.

Я думаю лучше разбить очистку сессий на подкаталоги так:

Ждём тему «Аномальное поведение кучи каталогов»

Иногда просто ls -la этой директории выполняется минут 200, причём iotop показывает загруженность IO процессом ls на 999%...

атомарна

Одна — да. Но их там как минимум две.

Предпочитаю безопасные советы опасным :-)

Вот посоветуешь на ходу сделать. Сделает, словит факап, а я потом виноват. Оно мне надо?

Ты в интернете. Just sayin'.

Чего две?

cd /var/lib/php5/  # это конечно операция,
                   # но она ни на что не влияет
mkdir sessions.new # аналогично
mv sessions.new sessions # бац, и все вновь
                         # создаваемые файлы будут
                         # уже в этой.

Одна операция. mv использует rename(2) про который чётко написано:

If newpath already exists, it will be atomically replaced, so that there is no point at which another process attempting to access newpath will find it missing. However, there will probably be a window in which both oldpath and newpath refer to the file being renamed.

sessions.new мы не используем, так что последнее не играет роли.

Да какой там факап на сессиях может быть :) В общем случае они вообще ненадёжны :)

Хотя не. mv переместит в каталог.

Ну тогда так:

name=`mktemp -dp . sessions.XXX`
ln -fTs $name sessions

тему «Аномальное поведение кучи каталогов» Иногда просто ls -la этой ддиректори выполняется минут 200, причём iotop показывает загруженность IO процессом ls на 999%...

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

Это не атомарное действие: если в момент когда cp уже закончится, а rm еще не начнется запишется что-то в sessions - ты этого не увидишь, потому что sessions будет удалена запущенным rm -rf

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

Да пофиг, самое страшное что там могло бы произойти это если бы в этот момент пользователь отправлял бы пост, то он получил бы ошибку «сессия устарела, перезагрузите страницу» или что-то такое.

Уже сделал ночью.

Что сделал-то?