스레드가 너무 많습니까?

서버를 작성 중이며 요청을 받으면 각 작업을 별도의 스레드로 보냅니다. 거의 모든 요청이 데이터베이스 쿼리를 작성하기 때문에이 작업을 수행합니다. 스레드 풀 라이브러리를 사용하여 스레드 구성 / 파괴를 줄입니다.

내 질문은 이것과 같은 I / O 스레드에 대한 좋은 차단 점은 무엇입니까? 나는 그것이 대략적인 추정 일 것이라는 것을 알고 있지만 우리는 수백 가지를 말하고 있습니까? 수천?

이 컷오프가 무엇인지 파악하려면 어떻게해야합니까?

편집하다:

귀하의 응답에 감사드립니다. 실 수를 계산하기 위해 테스트해야 할 것 같습니다. 문제는 그래요. 내가 그 천장을 쳤다는 것을 어떻게 알 수 있습니까? 정확히 무엇을 측정해야합니까?

어떤 사람들은 두 개의 스레드가 너무 많다고 말할 것입니다 -나는 그 캠프에 있지 않습니다 :-)

내 조언은 다음과 같습니다. 측정, 추측하지 마십시오. 한 가지 제안은 구성 가능하게하고 처음에는 100으로 설정 한 다음 소프트웨어를 공개적으로 배포하고 발생하는 상황을 모니터링하는 것입니다.

스레드 사용량이 3으로 정점에 도달하면 100이 너무 큽니다. 하루 종일 100으로 유지되면 최대 200까지 충돌하여 어떻게되는지 확인하십시오.

당신은 할 수 실제로 자체 사용을 모니터링하고 시작하지만 아마 잔인한 다음에 대한 구성을 조정하여 코드가 있습니다.

설명과 정교함 :

나는 자신의 스레드 풀링 하위 시스템을 롤링하는 것을 옹호하지 않습니다. 그러나 스레드에 대한 적절한 컷오프 지점을 요청했기 때문에 스레드 풀 구현에 생성 된 최대 스레드 수를 제한 할 수 있다고 가정합니다 (좋은 것입니다).

스레드 및 데이터베이스 연결 풀링 코드를 작성했으며 다음과 같은 기능이 있습니다 (성능에 필수적이라고 생각합니다).

• 최소 활성 스레드 수
• 최대 스레드 수
• 한동안 사용되지 않은 스레드를 종료합니다.

첫 번째는 스레드 풀 클라이언트 측면에서 최소 성능에 대한 기준을 설정합니다 (이 스레드 수는 항상 사용 가능합니다). 두 번째는 활성 스레드의 자원 사용에 대한 제한을 설정합니다. 세 번째는 리소스 사용을 최소화하기 위해 조용한 시간에 기준선으로 돌아갑니다.

사용하지 않는 스레드 (A)의 리소스 사용량과 작업을 수행하기에 충분한 스레드가없는 리소스 사용량 (B)의 균형을 유지해야합니다.

(A)는 일반적으로 메모리 사용량 (스택 등)입니다. 작업을 수행하지 않는 스레드는 많은 CPU를 사용하지 않기 때문입니다. (B)는 일반적으로 스레드가 사용 가능할 때까지 기다려야 요청이 도착할 때 처리가 지연됩니다.

당신이 측정하는 이유입니다. 당신이 말한대로, 대다수의 스레드는 데이터베이스에서 응답을 기다리고 있으므로 실행되지 않습니다. 허용해야하는 스레드 수에 영향을주는 두 가지 요소가 있습니다.

첫 번째는 사용 가능한 DB 연결 수입니다. DBMS에서 증가시킬 수 없다면 이는 어려운 한계 일 수 있습니다. DBMS가이 경우 무제한 연결을 취할 수 있다고 가정합니다 (이상적으로 측정해야 함).

그런 다음 스레드 수는 과거 사용에 따라 다릅니다. 달리는 최소값은 달리 한 최소값 + A %입니다 (예 : A와 같이 구성 가능). 5.

최대 스레드 수는 이전 최대 + B % 여야합니다.

또한 동작 변경을 모니터링해야합니다. 어떤 이유로 든 사용량이 상당한 시간 동안 100 % 사용 가능하게되어 (클라이언트 성능에 영향을 줄 수있는 경우) 다시 한번 B % 더 높아질 때까지 허용 된 최대 값을 늘려야합니다.

"무엇을 정확하게 측정해야합니까?" 질문:

구체적으로 측정해야하는 것은로드 상태에서 동시에 사용하는 최대 스레드 수입니다 (예 : DB 호출에서 리턴 대기 중). 그런 다음 예 를 들어 안전율 10 %를 추가하십시오 (다른 포스터는 내 권장 사항을 예로 들었으므로 강조했습니다).

또한 이는 프로덕션 환경에서 조정을 위해 수행해야합니다. 미리 견적을 받아도 괜찮지 만 어떤 프로덕션이 방해가 될지 모릅니다 (이러한 모든 것들이 런타임에 구성 가능해야하는 이유). 이는 예기치 않은 클라이언트 호출 배가와 같은 상황을 포착하기위한 것입니다.

이 질문은 매우 철저하게 논의되었으며 모든 답변을 읽을 기회가 없었습니다. 그러나 주어진 시스템에서 평화롭게 공존 할 수있는 동시 스레드 수의 상한을 살펴보면서 고려해야 할 몇 가지 사항이 있습니다.

1. 스레드 스택 크기 : Linux에서 기본 스레드 스택 크기는 8MB입니다 (ulimit -a를 사용하여 찾을 수 있음).
2. 주어진 OS 변형이 지원하는 최대 가상 메모리. Linux Kernel 2.4는 2GB의 메모리 주소 공간을 지원합니다. Kernel 2.6에서는 조금 더 큽니다 (3GB)
3. [1]은 지정된 최대 VM 지원 당 최대 스레드 수에 대한 계산을 보여줍니다. 2.4의 경우 약 255 개의 스레드입니다. 2.6의 경우 숫자가 약간 큽니다.
4. 어떤 종류의 커널 스케줄러가 있습니까? Linux 2.4 커널 스케줄러와 2.6을 비교하면 나중에 시스템에 존재하는 작업 수에 의존하지 않고 O (1) 스케줄링을 제공하지만 첫 번째 작업은 O (n) 이상입니다. 따라서 커널 스케줄의 SMP 기능도 시스템의 최대 지속 가능한 스레드 수에서 중요한 역할을합니다.

이제 더 많은 스레드를 통합하도록 스택 크기를 조정할 수 있지만 스레드 관리의 오버 헤드 (생성 / 파괴 및 스케줄링)를 고려해야합니다. 주어진 프로세스뿐만 아니라 주어진 스레드에 CPU 선호도를 적용하여 특정 CPU에 묶어 CPU 간 스레드 마이그레이션 오버 헤드를 피하고 콜드 캐쉬 문제를 방지 할 수 있습니다.

원하는대로 수천 개의 스레드를 만들 수 있지만 Linux에서 VM이 부족하면 프로세스 (임의의 스레드)를 임의로 시작합니다. 이것은 유틸리티 프로파일이 최대 값을 유지하지 못하게하기위한 것입니다. (유틸리티 기능은 주어진 양의 리소스에 대한 시스템 전체의 유틸리티에 대해 알려줍니다.이 경우 CPU 리소스 및 메모리가 일정한 리소스를 사용하면 유틸리티 곡선이 점점 더 많은 작업으로 평평 해집니다).

Windows 커널 스케줄러도 리소스를 과도하게 사용하기 위해 이러한 종류의 작업을 수행한다고 확신합니다.

[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/

스레드가 어떤 종류의 리소스 집약적 작업 (CPU / 디스크)을 수행하는 경우 한두 가지 이상의 이점을 거의 볼 수 없으며 너무 많으면 성능이 매우 빠르게 저하됩니다.

'최상의 경우'는 첫 번째 스레드가 완료되는 동안 나중 스레드가 중단되거나 일부는 경합이 적은 리소스에 오버 헤드가 낮은 블록이 있다는 것입니다. 최악의 경우는 캐시 / 디스크 / 네트워크를 스 래싱하기 시작하고 전체 처리량이 바닥에서 떨어집니다.

좋은 해결책은 요청을 풀에 배치 한 다음 스레드 풀에서 작업자 스레드로 디스패치하는 것입니다 (예, 지속적인 스레드 작성 / 파괴를 피하는 것이 첫 번째 단계 임).

그런 다음이 풀의 활성 스레드 수는 프로파일 링 결과, 실행중인 하드웨어 및 시스템에서 발생할 수있는 기타 사항에 따라 조정 및 확장 될 수 있습니다.

명심해야 할 것은 파이썬 (적어도 C 기반 버전)은 멀티 코어 머신의 성능에 큰 영향을 줄 수 있는 전역 인터프리터 잠금을 사용 한다는 것입니다.

멀티 스레드 파이썬을 최대한 활용 해야하는 경우 Jython 또는 다른 것을 사용하는 것이 좋습니다.

Pax가 올바르게 말했듯이, 측정하지 마십시오 . 내가 DNSwitness를 위해 한 일과 결과는 놀랍 습니다. 이상적인 스레드 수는 내가 생각했던 것보다 훨씬 많았습니다. 15,000 스레드는 가장 빠른 결과를 얻었습니다.

물론 그것은 많은 것들에 달려 있기 때문에 스스로 측정해야합니다.

Combien de fils d' exécution? 에서 완전한 조치 (프랑스어 만) ? .

많은 다중 스레드 응용 프로그램을 작성했습니다. 일반적으로 구성 파일에서 잠재적 스레드 수를 지정할 수 있습니다. 특정 고객을 위해 조정했을 때 모든 CPU 코어의 사용률이 꽤 높았지만 메모리 문제가 발생하지 않을 정도로 숫자를 높게 설정했습니다 (이는 32 비트 운영 체제 시각).

다르게 말하면 CPU, 데이터베이스 처리량, 디스크 처리량 등과 같은 병목 현상에 도달하면 스레드를 추가해도 전반적인 성능이 향상되지 않습니다. 그러나 그 시점에 도달 할 때까지 더 많은 스레드를 추가하십시오!

이것은 문제의 시스템이 앱 전용이며 다른 앱을 멋지게 재생할 필요가 없다고 가정합니다.

"큰 철"답변은 일반적으로 제한된 리소스 당 하나의 스레드 (프로세서 (CPU 바운드), 암 (I / O 바운드) 등)이지만 작업을 리소스의 올바른 스레드로 라우팅 할 수있는 경우에만 작동합니다. 액세스하십시오.

불가능한 경우, CPU (Fungable Resource)와 Fungable 리소스 (arm)가 있다고 가정하십시오. CPU의 경우 각 캐시를 특정 CPU에 할당하는 것은 중요하지 않지만 (캐시 관리에 도움이되지만) 암의 경우 스레드를 암에 할당 할 수없는 경우 큐 이론을 시작하고 암을 유지하기위한 최적의 수는 무엇입니까 바쁜. 일반적으로 사용 된 팔을 기반으로 요청을 라우팅 할 수 없다면 팔 당 2-3 개의 스레드를 갖는 것이 적절하다고 생각합니다.

스레드로 전달 된 작업 단위가 합리적으로 원자적인 작업 단위를 실행하지 않는 경우 문제가 발생합니다. 예를 들어 한 지점에서 스레드가 디스크에 액세스하고 다른 지점에서 네트워크를 대기하게 할 수 있습니다. 이렇게하면 추가 스레드가 들어와 유용한 작업을 수행 할 수있는 "크랙"수가 증가하지만 추가 스레드가 서로의 캐시 등을 오염시키고 시스템을 중단시킬 수있는 기회도 늘어납니다.

물론,이 모든 것을 실의 "무게"와 비교해야합니다. 불행히도 대부분의 시스템에는 매우 무거운 스레드가 있으며 "가벼운 스레드"라고하는 스레드는 전혀 스레드가 아니므로 낮은 수준에서 오류를 범하는 것이 좋습니다.

실제로 본 것은 매우 미묘한 차이로 인해 최적의 스레드 수에 엄청난 차이가 생길 수 있다는 것입니다. 특히 캐시 문제와 잠금 충돌로 인해 실제 동시성 양이 크게 제한 될 수 있습니다.

한 가지 고려해야 할 것은 코드를 실행할 머신에 몇 개의 코어가 있는지입니다. 그것은 주어진 시간에 얼마나 많은 스레드가 진행될 수 있는지에 대한 하드 한계를 나타냅니다. 그러나 사용자의 경우와 같이 스레드가 데이터베이스에서 쿼리를 실행하기를 자주 기다리는 경우 데이터베이스에서 처리 할 수있는 동시 쿼리 수를 기반으로 스레드를 조정하려고 할 수 있습니다.

나는 이것이 당신의 질문에 약간의 회피라고 생각하지만 왜 프로세스에 포크하지 않습니까? 네트워킹에 대한 나의 이해 (흐릿한 시절부터 네트워크를 전혀 코딩하지는 않음)는 들어오는 각 연결을 별도의 프로세스로 처리 할 수있었습니다. 전체 프로그램을 핵 공격하십시오.

ryeguy, 나는 현재 비슷한 응용 프로그램을 개발 중이며 내 스레드 번호는 15로 설정되어 있습니다. 불행히도 20으로 늘리면 충돌합니다. 따라서, 이것을 처리하는 가장 좋은 방법은 현재 구성이 X 이상의 스레드 수를 허용하는지 여부를 측정하는 것입니다.

대부분의 경우 스레드 풀이이를 처리하도록 허용해야합니다. 일부 코드를 게시하거나 자세한 정보를 제공하면 스레드 풀의 기본 동작이 가장 좋지 않은 이유가 있는지 더 쉽게 확인할 수 있습니다.

작동 방식에 대한 자세한 정보는 http://en.wikipedia.org/wiki/Thread_pool_pattern 에서 확인할 수 있습니다 .

CPU 코어만큼 많은 스레드가 제가 자주 들었습니다.