thread가 있는데 fwrite를 합니다.
보통 tick count 5쯤 걸립니다.
근데 같은 thread가 하나 더 뜨면
6-7정도 걸리다가 10~30초쯤 마다 엄청 오래걸립니다.
대략 30~100 정도요.
이러면 받아오는 데이타를 유실하게됩니다.
왜 이럴까요?
뭘 살펴봐야할지라도 가르쳐주세요
fwrite()에서 블록되어, 데이터 수집루틴 부분이 제시간에 수행되지 않아 데이터의 손실이 있는 것으로 생각됩니다. fwrite()가 블록되는 경우는 커널의 버퍼캐시의 delayed write메카니즘(버퍼캐시가 풀되면 실제 물리장치에 쓰거나, 약 30초정도후에 실제 물리장치에 쓰는 5가지 시나리오에 의해 동작하는 메카니즘)에 기인한 것으로 예측됩니다.
fwrite()가 사용하는 라이브러리상의 버퍼크기를 man setbuf(3)를 사용해서 버퍼크기를 아주 크게 늘려주면서 실험해 볼 수 있으나, 이 또한 한계에 도달할 것으로 보입니다.
해결방법은,
1) 보다 빠른 저장매체를 사용하는 것 : RAID도 고려할 수 있겠지요?
2) 소프트웨어적으로는 /....
fwrite()를 호출하는 쓰레드를 t1 이라고 가정할때, 저장하는 데이터의 생성/수집을 t1 에서 행하고 디스크에도 저장한다면, 이를 분리하십시요.
t1 을 t1-1, t1-2로 분리하여, t1-1에서는 데이터를 생성/수집하고, t1-2에서는 데이터를 저장(fwrite)하도록 메카니즘을 변경해 보세요. 둘사이에는 당연히, IPC가 필요한데, 공유메모리나, 유닉스도메인 소켓등으로 IPC를 생성하도록 하시고요.
fwrite()에서 블록되어,
fwrite()에서 블록되어, 데이터 수집루틴 부분이 제시간에 수행되지 않아 데이터의 손실이 있는 것으로 생각됩니다. fwrite()가 블록되는 경우는 커널의 버퍼캐시의 delayed write메카니즘(버퍼캐시가 풀되면 실제 물리장치에 쓰거나, 약 30초정도후에 실제 물리장치에 쓰는 5가지 시나리오에 의해 동작하는 메카니즘)에 기인한 것으로 예측됩니다.
fwrite()가 사용하는 라이브러리상의 버퍼크기를 man setbuf(3)를 사용해서 버퍼크기를 아주 크게 늘려주면서 실험해 볼 수 있으나, 이 또한 한계에 도달할 것으로 보입니다.
해결방법은,
1) 보다 빠른 저장매체를 사용하는 것 : RAID도 고려할 수 있겠지요?
2) 소프트웨어적으로는 /....
fwrite()를 호출하는 쓰레드를 t1 이라고 가정할때, 저장하는 데이터의 생성/수집을 t1 에서 행하고 디스크에도 저장한다면, 이를 분리하십시요.
t1 을 t1-1, t1-2로 분리하여, t1-1에서는 데이터를 생성/수집하고, t1-2에서는 데이터를 저장(fwrite)하도록 메카니즘을 변경해 보세요. 둘사이에는 당연히, IPC가 필요한데, 공유메모리나, 유닉스도메인 소켓등으로 IPC를 생성하도록 하시고요.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.