파일스트림 최대 개수에 대해..
안녕하세요
다수의 파일을 동시에 작성하는 기능을 구현하고 있는데 어려움이 있어 질문 드립니다
작업환경은 MFC 입니다
1. 파일은 .txt형태이며 100ms마다 1개의 라인이 작성 되야 합니다(1초에 10개 라인 작성됨)
- 파일은 4가지의 작성 타입이 있습니다
- 160개의 채널이 존재하며 채널마다 4가지의 타입의 데이터가 필요합니다
- 따라서 (160개 채널*4가지 파일타입) == 640개의 파일이 동시에 작성 되어야 합니다
2. 파일 작성을위해 총160개의 같은 일을하는 스레드가 있습니다
- 160개의 스레드는 채널 갯수 만큼 생성 하였습니다
- 스레드는 큐(작성할 결과데이터 보관용)에 적재된 순서대로 순차적으로 파일을 작성 합니다
- 4가지 형태의 작성 타입을 위해 4개의 파일핸들러를 핸들링 합니다
- CStdioFile 클래스를 사용 합니다
3.발생되는 문제
- 파일 작성시 파일오픈을 하지 못하여 작성을 실패하는 현상이 나타납니다
4.현상 파악을 위한 행위
- 큐에 적재된 데이터가 많아서 그런가 싶어 100ms 마다 큐적재 에서 1000ms 마다 적재 시도, 현상 동일
- 작성될 타입을 4개에서 1개로 줄여(총480개의 핸들러) 시도, 현상 사라짐
사용되는 파일핸들러를 줄이니 현상이 사라 졌습니다
그렇다고 4가지 타입에서 3가지 타입으로 작성될순 없으니
방법을 찾아야 하는데 쉽지가 않습니다..
당장드는 생각은 파일핸들러를 핸들링할 수 있는 최대 개수가 존재하여 오픈을 실패 하는게 아닐까 싶어
최대 개수를 늘리면 해결 가능해 보이는데 왠지 느낌이 쌔하고
채널마다 가지고 160개의 스레드가 필요 이상으로 많아 보이는것 같아
처리하는 관리 포인트를 줄이면 어떨까 라고 생각했지만..
필요한 파일핸들러는 640개인데 최적화에 의미가 있지 현상을 해결할 수 있는 방법은 아닌것 같고..
도와주세요!!ㅠㅠㅠ 이제막 입사한 신입인데..SW팀은 저혼자라 물어볼 선배도 없고
비슷한 경험 있으신분은 답변 부탁 드립니다~!!
문제의 원인을 찾기 보다는 구조를 좀 바꾸면 어떨까요
문제의 원인을 찾기 보다는 구조를 좀 바꾸면 어떨까요?
4가지 타입의 데이타를 저장하는 4개의 쓰레드를 두고,
4개의 쓰레드에서 한번에 하나의 파일만 열고, 쓰고, 닫고.
그러면 동시에 4개의 파일만 항상 open되니. 동시에 open되는 파일 handle 문제는 괜찭지 않을까요?
100msec마다 1라인이면 그렇게 데이타 양이 많지 않은 것 같아서 가능한 방법인것 같습니다.
윗분 말처럼 구조 정리가 필요해 보입니다.
윗분 말처럼 구조 정리가 필요해 보입니다.
파일의 사이즈가 정상적으로 종료되면 얼마나 되나요? 그렇게 크지 않다면 파일에 저장하는 것이 아니라 메모리를 충분히 할당해서 실행 도중에는 메모리에 저장하고 다 종료되면 마지막에 파일에 쓰는 형식이 어떨까 싶네요.
채널이 어떻게 외부(다른 프로세스)와 통신하는지 모르겠는데 TCP/IP면 쓰레드 갯수를 최소화하고 select() 등으로 멀티 입력을 처리하는 구조를 일단 생각해 볼 수 있겠네요.
제약은 [1] WIN32 API 차원에서도 걸릴 수
제약은 [1] WIN32 API 차원에서도 걸릴 수 있고, [2] 사용중인 CRT에 의해서도 걸릴 수 있으며, [3] MFC에 의해서도 걸릴 수 있겠습니다.
[1]은 충분히 큰 것 같습니다. 구글 검색해보니 일단 16384라는 숫자가 나오네요 ( https://stackoverflow.com/questions/870173/is-there-a-limit-on-number-of-open-files-in-windows ).
[2]는 컴파일러마다 달라질 수 있겠는데, VC의 경우 아래 글을 보니 _open, _read, and _write 등을 쓸 경우 8192이고, fopen, fgetc, and fputc 등의 스트림I/O를 쓸 경우엔 512로 더 작지만 _setmaxstdio() 함수를 이용해 8192까지 늘릴 수 있는 모양입니다.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?redirectedfrom=MSDN&view=vs-2019
[3]은 잘 못 찾겠네요. afx.h 헤더파일을 대충 보니, CFile은 CRT를 거치지 않고 WIN32 API를 바로 감싸 만든 클래스인 것 같고, CStdioFile은 CRT의 스트림I/O를 감싼 클래스인 것 같습니다. [1], [2]를 참고할때, CFile을 쓸 경우 WIN32에 의한 16384 한계가 있겠고, CStdioFile을 쓸 경우 CRT 스트림I/O에 의한 기본한계 512를 _setmaxstdio()로 8192까지 늘릴 수 있을 것 같습니다. CFile/CStdioFile 자체의 제약이 더 있을지는 실험해보면 알 수 있겠는데 해보진 않았습니다.
결론은, CStdioFile을 쓰신 상황에서는 _setmaxstdio()를 이용하면 갯수제약 문제가 해결될 수 있겠다는 것입니다. 640은 안 되고 480은 되는 상황도 여기에 부합되는 것 같고요. 그런데 이렇게 한계를 늘리는 방식 말고 다른 분들 의견처럼 구조변경도 고려해보시면 좋겠네요.
좋은 정보네요!
좋은 정보네요!
답변 감사합니다!!
갯수제약에 따른 문제 발생으로 나름의 정의를 내렸으며
(500개 이상의 핸들러 사용과 그이하 사용 했을시 나타나는 현상 근거로)
적용되어 있는 구조가 위내용과 같이 불필요 이상의 것들이 많아
최적화 목표로 이것저것 흔들어 보고 있습니다^^;;
채널당 저장해야할 목표 사이즈의 단위가 GB까지 가능하니 DB접근도 고려해 보고 있습니다
사실 필수 같구요ㅠㅠㅋㅋ 해결에 있어 많은 단서가 되었습니다
감사합니다!!
댓글 달기