iperf 스레드는 프로세서 선호도를 존중하지 않습니다.

iperf 스레드는 프로세서 선호도를 존중하지 않습니다.

Ubuntu 시스템(14.04 LTS)에서 서버 모드로 iperf를 실행하고 있습니다. 하드웨어는 하이퍼스레딩 기능이 있는 쿼드 코어이므로 사용 가능한 코어는 0~7개입니다(0은 4와 쌍, 1은 5와 쌍 등).

실행 중인 iperf 프로세스의 프로세서 선호도를 프로세서 0,1만 사용하도록 설정했습니다. 작업 세트를 사용하여 이를 확인할 수 있습니다.

$ taskset -pc 27745
pid 27745's current affinity list: 0,1

top 또는 htop에서 프로세스를 보면 프로세스가 이러한 코어 중 하나에서만 실행되는 것으로 올바르게 표시됩니다. 그러나 스레드 보기로 전환하면 임의의 코어에서 실행 중인 하위 스레드가 표시됩니다.

top/htop이 어떤 식으로든 나를 오해하게 합니까? 정말 이런 일이 일어날 수 있을까요? 그렇다면 그 이유와 예방 방법은 무엇입니까?

편집하다

iperf에서 이것을 본 적이 있지만 반드시 iperf에만 국한된 것은 아니라는 점을 말씀드리고 싶습니다. 이것이 내 설정입니다. 이것을 알아낼 수 없으면 다른 실행 파일을 시도하여 동작이 재현 가능한지 확인할 수 있습니다.

답변1

나는 이것에 대한 진실을 배웠습니다. 이는 제가 ansible에서 iperf를 시작한 특이한 방식 덕분입니다. 처음에는 iperf에 데몬 모드( )가 있는 것을 발견하지 못했기 -D때문에 iperf를 수동으로 시작했습니다 daemon. 나는 이것을 잊어버렸고 그것을 바꿀 시간이 없었다.

이상한 점은 이 방법을 사용하여 iperf를 시작하면 추가 스레드가 즉시 생성되는 것 같다는 것입니다. 자식 프로세스를 적절하게 분리하기 위해 자식 프로세스를 시작해야 한다는 뜻은 아닙니다 daemon(즉, 프로세스 그룹 리더가 아니라 프로세스 그룹의 자식인지 확인하는 init등). iperf 프로세스 자체는 시작되면 몇 가지 추가 스레드를 시작합니다(이것이 실제로 작업의 측면이 아닌 한 daemon- 그러나 이를 기반으로 스레드로 표시됨 htop).

taskset데몬 및 iperf 프로세스에 대한 좋은 측정값을 얻었지만 이것이 하위 스레드를 놓친 것 같습니다(이 문제에 대한 논의는 여기를 참조하십시오 :실행 중인 프로세스의 선호도를 작업 세트로 설정하지 못했습니다.). 올바른 프로세서에서 실행되는 주요 iperf 프로세스를 볼 수 없기 때문에 이것이 전체 이야기라고 믿지 않습니다. 그래서 수상한 일이 일어나고 있습니다. 나는 이것이 더 나은 조사 행동으로 설명될 수 있다고 믿지만 daemon지금은 조사할 시간이 없으므로 그대로 두겠습니다.

관련 정보