Есть куча директорий с более чем 10 000 файлами в каждой. Надо оптимальнее (минимум нагрузки на сервер) получить размер этих файлов, причем данные нужны на каждой итерации программы только по одной директории. 

Если для каждого файла вызывать 10 000 раз функцию stat (или аналогичную), то создается ненужная нагрузка на сервер. Да и если файловая система подключена по NFS то на сеть доп. нагрузка и соответственно долго работает.

Для примера привожу код (не проверял):

 
Вопрос такой: возможно ли заменить 10 000 вызовов на один для каждой директории? Никто не встречался с аналогичной проблемой?


Работать скрипт должен на Unix и Windows

есть распределенная файловая система MogileFS (она кстате на perl написана)
на ней можно быстро подсчитать это... через mysql

gcc:
спасибо за вариант, но это не промышленное решение - мне не подходит:

# работает под Linux(Ubuntu), а мне надо еще под HP-UX, Windows *
# Как видно из архитектуры сервер БД - единая точка отказа. При выходе его из строя падает все.
# Производительность решения ограничена производительностью сервера БД.

нельзя. т.к. файловые системы (по крайней мере общеупотребительные) не предусматривают хранение размеров всех файлов какого-то каталога в какой-то отдельной области (типа inode). Как бы это ни было завуалировано, но всегда будет развёртка (явно или неявно) в итеративную проверку каждого файла. 
Возможно будет, если вы сами напишите свою ФС с подобной структурой (для каждого элемента хранятся размеры всех его субэлементов, но подобная структура совершенно очевидно избыточна) и драйвера к ней для перечня ОС, на которые предполагается портировать решение.  

Если душа требует краткости кода, то распарсивайте результаты системных вызовов типа "du -hS /Some/Dir"  

И да, если вы стремитесь соптимизировать, то начните с пересмотра структуры хранения БД, ибо 10+ тыс.файлов в каждой папке это имхо изъян в проектировании системы.

Это сообщение отредактировал(а) ming - 18.3.2010, 14:39

есть kqueue интерфейс в ядре FreeBSD, который может наблюдать за файлами/каталогами/сокетами
(навреное можно наблюдать создался ли файл а какталоге, какой переместился или изменился)

аналог inotify в linux

http://ru.wikipedia.org/wiki/Kqueue
http://ru.wikipedia.org/wiki/Inotify
http://www.ibm.com/developerworks/ru/libra...ubuntu-inotify/

Это сообщение отредактировал(а) gcc - 18.3.2010, 15:55

Ну есть inotify , а какое отношение оно имеет к вопросу?

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


Это сообщение отредактировал(а) gcc - 18.3.2010, 16:26

может, для какого-то случая это и пройдёт, кстати.

"то распарсивайте результаты системных вызовов типа "du -hS /Some/Dir" "

Спасибо за совет. imho правильнее ls -l /Some/Dir
Однако не ПЕРЕНОСИМО (WINDOWS), да и вызов дочернего процесса все-таки думаю будет дороже

"то начните с пересмотра структуры хранения БД, ибо 10+ тыс.файлов в каждой папке это имхо изъян в проектировании системы."

Полностью с Вами согласен. Однако это банковская система и так УЖЕ сделано. Изменить нельзя. В директориях хранятся какое- то время файлы отчеты по транзакциям по каждому терминалу за каждый день. Мне надо периодически проверять не изменились ли эти файлы (кто знает, поймет - PCIDSS). Хочется гибкости, простоты и переносимости - поэтому я уже написал программу на перле, которая считает MD5 для каждого файла и сохраняет это все в отдельном файле. При следующем запуске читает сохраненное ранее значение и сравнивает с тем что сейчас. Разницу пишет в отдельный протокол. Кстати stat для этих файлов работает очень быстро, поэтому вопрос можно снять. Мое решение переносимо, то есть работает и на виндах и на unix и бесплатно.

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

Сейчас я смотрю как без установки дополнительных модулей в перл и переносимо (Unix&Windows) в реальном времени отправлять сообщения об этих изменениях на SYSLOG сервер по сети. Модуль UNIX:SYSLOG не понравился тем, что в дистрибутиве виндов (Activestate) он не включен в стандартную поставку. Заморачиваться с отдельной установкой этого модуля на куче виндовых серваков не хочется. Поэтому сижу, читаю спеку по SYSLOG чтобы реализовать самому (в требуемом мне объеме). Пока не сложно, однако нет времени, так как у меня разработка ПО - это больше хобби, чем работа.