Я использую лексический поиск f $ во многих моих сценариях DCL, но никогда не сталкивался с какой-либо проблемой, пока не было около 10k файлов в каталоге DCL для поиска из ... теперь в этом случае поиск f $ идет медленнее при поиске из огромного количества файлов, и я подозреваю, что есть влияние на производительность ... так что хотелось бы знать, действительно ли f $ поиск идет медленно, если в каталоге огромное количество файлов или там это еще одна причина этого медлительности, и если да, то какова может быть вероятная причина? Пожалуйста, дайте мне знать, если требуется какая-либо другая информация.
ответ
Да, f $ поиск по большому каталогу может быть медленным. Это может привести к замедлению, вызванному действию t или его можно замедлить из-за активности внешнего каталога. Каталоги - это простые последовательные файлы с записью для имен файлов в алфавитном порядке. Они начинаются «плотно», но со временем становятся «разреженными». Если новое имя добавляется к блоку посередине, и этот блок слишком заполнен, остальная часть каталога будет перетасовываться, чтобы освободить место. Это может занять сотни IO и блокировать F $ SEARCH. Если последняя запись в блоке удалена, остальные перетасовываются вниз. Шаффле был блоком за раз, а теперь (6.2?) Стал 32 блока (mcr sysgen show acp_maxread) Так что все зависит. Пожалуйста, предоставьте более подробное описание «замедление» - версия OpenVMS - шаблон поиска: подстановочный знак или конкретный (лучше)? - Перезапуск каждого поиска или в цикле с контекстом (лучше!) - Типичный шаблон имени? Наибольшая вариация в первых 4 или 5 символах.
Перспективные данные о производительности, возможно, от T4 или, по крайней мере, указание от MONI FILE и MONI FCP?
Удачи вам! Hein
Рассмотрите возможность внесения изменений. 10K файлов в одном каталоге, часто лучше - это записи в файле, а не файлы в каталоге. Подсистема каталога на самом деле не предназначена для использования таким образом. (извините, что не очень полезно). Более новые версии VMS позволяют предварительно распределять каталог с большим количеством блоков ($ CREATE/DIR/ALLOCATION = nnnnn). Это может помочь.
Для исправления вы можете создать новый.dir с значительным распределением (посмотрите, насколько велик старый каталог), а затем переименуйте файлы из старого каталога в новый каталог.
$ create/dir/alloc=500 disk:[new]
$ rename [old]*.*;* disk:[new]*.*;*
Затем удалите старый каталог (должен быть пустым) и переименуйте новый каталог в старый каталог.
Обязательно выполняйте указанные выше операции, если процесс не создает или не выполняет доступ к файлам в каталоге.
Как сказал Хейн, это плохая практика иметь 10000 файлов в каталоге. Вам действительно нужно иметь все эти файлы в Интернете? Проверьте lib/insert для хранения такого большого количества файлов удобным способом. – user2915097