hanging problem circumvent: records into small chunks

[fgenie]

MATH에서만 유독... pqdm iteration이 모두 끝난 후 collecting results가 무한정 오래걸리는 문제가 있었다. tqdm과 multiprocessing 을 같이 사용하면 이런 일들이 일어난다는 보고들이 있지만 깔끔하게 해결된 바 없는 것 같다.

하지만 total number of iteration이 줄면 이런 현상이 발생하지 않는다. 그리고 다른 데이터셋에는 이런 문제가 없다. 아마도 IPC 할 때 순서 맞추기가 어려운 문제가 있는 것 같다. 원래 row들의 순서대로 다시 붙여놔야하는데 MATH는 row 당 스트링이 많이 들어있으니까 subprocess들끼리 이것들 비교해가면서 순서를 맞추는데에 드는 통신시간이 total number of iteration 의 subquadratic하게만 늘어난다고 생각해도 이런게 일어날 수 있다. 유독 MATH의 row 별로 들어있는게 많기도 하고 갯수도 5000개라 1000개씩 잘라서 하고 있었으니까 이게 맞는 설명이 아닐까 하고 생각하고 있다. rims를 수행할 때는 baseline 결과 row들을 가지고 하니까 더 많은 것들이 포함되어있을거고 그걸 500개씩 한 번에 수행시키니까 작업 마지막에 거의 hang 되는게 아닐까 CPU도 1 core를 다먹고 메모리는 널널하다.

그래서 30개씩 잘라서 pqdm을 반복하도록 했다. 같은 문제가 더 발생하지 않았으면 좋겠는데...

[fgenie]

이래도 문제가 해결되지 않는다 PR은 다음에

[fgenie]

이 문제가 추후에 크게 문제가 된다면 Async구현으로 바꿔서 해결해볼 수 있는 여지가 있을 것 같다... 아니면 코어랑 메모리 빵빵한 DGX에서 실행해보기? 다른 해결책은 딱히 생각나지 않는다.

[fgenie]

당장 DGX접근이 어려워서 실험 프로세스의 NICE값을 줄이는 것으로 대응중이다. n_jobs=6일 때 Collecting result가 CPU를 엄청 잡아먹는다. 리소스 문제였던 것.

[fgenie]

아니 근데 진짜 MATH row가 그렇게 큰가? 라는 의문이 있었는데 해결됐다. 3500~3600번대 row에 파일 평소 row의 100배쯤 되는 스트링을 포함하는 PAL 결과가 들어있었다. (두 개). 제거하고 나서는 해결됨.