12. maj 2003 - 00:17Der er
20 kommentarer og 1 løsning
Antal threads pr. process
Jeg har netop installeret Redhat 8.0 på en maskine. Her skal jeg køre en server applikation (programmeret i Java), der skal kunne håndtere mindst 3000 samtidige threads.
På Windows NT Server, virker det helt perfekt, og programmet kan uden problemer køre med langt over 3000 samtidige threads.
Men på RedHat kan jeg ikke komme op på mere end omkring 2100 samtidige threads i samme program. Det ser ud til at den løber ind i en eller anden øvre grænse angående stack size per process/program. For hvis jeg angiver at Java VM kun skal benytte en stack size på 256KB pr. thread (mod 512KB som default), så kan jeg lave ca. dobbelt så mange threads. Men jeg vil naturligvis helst ikke lave den tildelte stack size pr. thread mindre end default, da dette vil øge risikoen for Stack Overflows.
Det er heller ikke fordi computeren mangler resourcer - da jeg tested det, var der hele tiden mindst 800MB ram ledig, og jeg sagtens kan starte flere instanser af programmet samtidig, hvor hver instans fint køre med de 2100 samtidige threads. Men det skulle jo gerne være ét program der kan have mindst 3000 threads.
Kan det passe at der er en sådan øvre grænse et eller andet sted? Og hvordan kan denne fjernes, så jeg kan lave flere threads pr. program/process.
dank > Den kernel version jeg har er den der kommer med RedHat 8.0, som vidst nok er version 2.4.18-19.8.0. I den side du sendte står der ikke noget angående kernel 2.4x.
Jeg læste et sted at man kunne rette i filen "/proc/sys/kernel/threads-max", men denne står allerede til 14336.
Som sagt, hvis jeg nedsætter størrelsen pr. thread stack til 256K, så kan jeg lave ca. dobbelt så mange threads. Så det ser ud som om den løber ind i en øvre grænse når størrelsen på alle thread stacks tilsammen er omkring 1GB, per program. En thread stack bruger virtual memory (ikke ram), så jeg skulle mene at det er address space jeg løber tør for..
Så jeg tror spørgsmålet må være: Hvordan kan kan jeg forøge den max tilladte mængde af virtual memory/address space en applikation/process kan bruge?
Det er formentlig stadig en kernel rebuild der skal til.
Nu kender jeg ikke Linux virtual address space, men hvis det er 32 bit flat, så kan du jo snart komme i problemer, da 4 GB ihvertfald er absolut max. og hvis f.eks. kun halvdelen kan bruges til stack er 2 GB max. og hvis halvdelen er til system og kun halvdelen af resten er til stack, så er det 1 GB.
Husk iøvrigt at roterende virtuelt hukommelse er meget langsomt !
arne_v > det er et netværks applikation der kommunikere med klienter; derfor bliver vi nødt til som minimum at have én thread pr. klient. På NT køre den fint med omkring 2500-3000 samtidige klienter, og et CPU forbrug på omkring 20-30%.
Jeg ved at vi kunne benytte java's nye non-blocking IO, for at servicere flere klienter pr. thread, men det ville tage utrolig lang tid at omskrive hele applikationen til dette. Efter tests med non-blocking IO, på windows stødte jeg også på et par fatale bugs, der ikke er rettet endnu.
Hvis maskinen kun er udstyret med 1CPU installeres kerne.... - hvis der er flere installeres kerne-smp... - som standard understøtter 2Gb - og kerne-enterprise... understøtter > 4Gb.
Hvilken kerne er installeret? (uname -a)
Problemet kan alene være shared_memory, som kan rettes on-the-fly - og under boot vha. /etc/sysctl.conf
lap > kernel.shmmax kan ikke sættes til en højere værdi end 33554432 (som den allerede står til). Applikationen "Kernel Tuning" der følger med RedHat, gør det muligt editere værdierne i /etc/sysctl.conf via en grafisk brugergrænseflade. Og den tillader altså ikke at kernel.shmmax bliver sat til mere end 33554432.
arne_v > I /boot/config-2.4.18-14 er min setting også "CONFIG_1GB=y". Jeg ville meget gerne blot ændre dette til "CONFIG_2GB=y". For det er helt sikkert her mit problem ligger. Men for at dette får nogen som helst virkning, skal der laves en komplet rebuild af kernel. Se: http://www.mail-archive.com/java-linux@java.blackdown.org/msg15251.html
Jeg har læst lidt om hvordan man rebuilder sin kernel på redhat.com, men det ser mildest talt ikke særlig nemt ud.. Og jeg tror ikke at dette er noget jeg vil begive mig ud i lige med det samme. Til at starte med vil jeg blot prøve at reducere stack size pr. thread til 256K, og se om det så ikke går an.
Du er meget velkommen til at "svare" så du kan få dine point, og vi kan få lukket spørgsmålet. Der kan jo gå lang tid før jeg får taget mig sammen, og forsøger en kernel rebuild. :)
dank > Øøhh, nope. Nu ved jeg hvad der skal ændres for at løse problemet!!! Hvad mere kan man forlange? Linket du sendte fortalte ikke noget om mit problem angående virtual address space (CONFIG_1GB, CONFIG_2GB). Om jeg rebuilder i dag eller om en måned kan ligsom ikke være dit problem.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
