LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


1

5

Есть одна директория, содержащая только 32 директории с названиями от 0 до v. В каждой такой директории ещё по 32 с такими же именами, в которых примерно по 20-30 файлов.

Как вы догадались, это директория с сессиями. Так вот, почему-то Иногда просто ls -la этой директории выполняется минут 20, причём iotop показывает загруженность IO процессом ls на 99% и скорость чтения несколько МБ/с. O_o В директории всего 32 директории и больше ничего, чего там можно так долго читать на такой скорости? Причём на время выполнения ls доступ к сессиям блокируется и все запросы, которые используют сессии, зависают. И это не только ls, если просто набрать /var/lib/php5/ и нажать [tab], то происходит аналогичное, iotop показывает что процесс bash занял 99% IO, что-то читает долго.

Странно что вообще сессии блокируются, если файлы сессий расположены в поддиректориях типа /var/lib/php5/x/x/, а я всего лишь просматриваю содержимое директории /var/lib/php5, где кроме 32х директорий ничего нет.

Как такое может быть?

Дебиян, LAMP, VPS под OpenVZ (да, знаю что говно, сервер не мой), если что.

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

Nasreddin_Hodja ()
Ответ на: комментарий от Deleted

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

MrClon ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от i-rinat

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

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

Nasreddin_Hodja ()
Ответ на: комментарий от post-factum

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

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

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

Nasreddin_Hodja ()
Ответ на: комментарий от Nasreddin_Hodja

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Nasreddin_Hodja

309M

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Первый это проверить раздел с помощью 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

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

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

Nasreddin_Hodja ()
Ответ на: комментарий от Nasreddin_Hodja

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

Nasreddin_Hodja ()
Ответ на: комментарий от Nasreddin_Hodja

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

ext4

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

anonymous ()
Ответ на: комментарий от Nasreddin_Hodja

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

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

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

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

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

anonymous ()
Ответ на: комментарий от KRoN73

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Чего две?

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 мы не используем, так что последнее не играет роли.

anonymous ()
Ответ на: комментарий от i-rinat

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

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

Ну тогда так:

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от Nasreddin_Hodja

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

Nasreddin_Hodja ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.