많은 DCL 스크립트에서 lexical f $ search를 사용하고 있지만 검색 할 DCL 디렉토리에 약 10k 개의 파일이있을 때까지는 아무런 문제가 발생하지 않았습니다 ...이 경우 f $ 검색은 엄청나게 많은 수의 파일을 검색하는 데 시간이 많이 걸리고 일부 성능에 영향을 줄 수 있다고 생각합니다 .... 그래서 디렉토리에 파일 수가 많거나 거기에 파일 수가 많으면 실제로 f $ 검색이 느려지는지 알고 싶습니다. 이 속도가 느린 이유가 무엇입니까? 그렇다면 가능한 이유는 무엇입니까? 다른 정보가 필요한 경우 알려주십시오.
예, 큰 디렉토리에서 f $ 검색이 느려질 수 있습니다. 외부 디렉터리 작업으로 인해 속도가 느려질 수 있으며 느려질 수 있습니다. 디렉토리는 알파벳 순으로 파일 이름 레코드가있는 단순 순차 파일입니다. 그들은 '고밀도'로 시작하지만 시간이 지남에 따라 '희박한'것이됩니다. 중간에있는 블록에 새 이름이 추가되고 해당 블록이 너무 꽉 차면 디렉토리의 나머지 부분이 섞여 방이 만들어집니다. 수백 개의 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)으로 사전 할당 할 수 있습니다. 도움이 될 수 있습니다.
재조정을 위해 크기가 큰 할당으로 new.dir을 생성 한 다음 (이전 디렉토리의 크기를 확인) 이전 디렉토리의 파일 이름을 새 디렉토리로 바꿀 수 있습니다.
그런 다음 이전 디렉토리를 삭제하고 (비워 두어야 함) 새 디렉토리의 이름을 이전 디렉토리로 변경하십시오.
디렉토리에서 파일을 생성하거나 액세스하는 프로세스가 없으면 위와 같이하십시오.
Hein이 말한 것처럼 디렉터리에 10000 개의 파일을 저장하는 것은 좋지 않습니다. 온라인으로 모든 파일을 정말로 갖고 있어야합니까? 이러한 많은 수의 파일을 편리하게 저장하려면 lib/insert를 확인하십시오. – user2915097