Keresés

IBM-nek van unofficial patche linuxhoz, áll 1 db kernelpatchból meg egy sharedlibből. Azzal lehet qrvasok threadet (akár több tízezret) is csinálni. A project neve: NGPT (rendkívül fantáziadús Next Generation Posix Threading). Ez ugyanis nem 1-1, hanem sok-sok modell szerint threadol, ami klafa.

OFF (Nem, a jo megoldast a (2)-es hozzaszolasomban irtam meg :).

Nem eszik olyan forron a kasat. Egy helyi guru segitsegevel epp most konfiguraljuk at a linuxthread library-t, epp a kernel es a glibc ujraforditasa folyik.

Ha minden sikerul, kitoljuk a processzenkenti thread limitet 4096-ra. (Azon az aron, hogy a thread -ek rendelkezesere allo stack a negyedere csokken, de meg igy is fel mega lesz, szoval elmeletileg nem lesz gond.)

Mindenesetre izgalmas volt levadaszni a (remelhetoleg jo) megoldast az internetrol...

Attol felek, hogy igazad van. Tanulsag: Java-t eldobni, C-t elovenni, non-blocking uzemmodot megismerni....

A JDK1.3-tol mar nem tamogatja a SUN a green thread-eket, csak a nativ-ot.

A sok thread meg ayert kell, mert direct-socket kapcsolatot akarok sok-szaz user fele (gondolj egy chat-re pl.)

JAVA alatt a socket olvasas blokkol, tahat minden userhez kulon olvaso szal kell, es ajanlott az irashoz is mindenkinek kulon szal, kulonben ha hiba van broadcast-nal egy socket-ben, akkor leallhat az egesz, amig nem telik le a time-out.

Azaz a 900 thread kb. 400 userre eleg.

Van valami olyan csodasag hogy GreenThreads, amikor nem indit fizikailag kulon thread-et, hanem o maga utemez a logikai threadek kozott... egyebkent mi a torpre kell neked ennyi thread?

Linux alatt szeretnek JAVA alapu szerver-alkalmazast futtatni.
A JDK1.3.1 nativ szalakat indit minden JAVA-s szalhoz.

A problemam az, hogy a SUN altal kiadott JDK max kb 900 szalat tud inditani. nekem ennek a tobbszorose kellene...

Itt van egy angol nyelvu leiras a SUN-tol a hiba magyarazataval. Az egyertelmuen kiderul szamomra belole, hogy most semmi keppen nem fogom tudni hasznalni a telepitett linuxomat.

De egy kis esely talan meg maradt... Ha valaki ismeri az uj 2.4 -es (?) kernelt, es elolvasna az alabbiakat, meg tudna nekem mondani, hogy erdemes-e kiserleteznem egy uj kerneles verzio felrakasaval, van-e esely ra, hogy ott mar tudjak tobb szalat inditani ?
(nekem gozom sincs rola, hogy atdolgoztak-e a process-kezelest)

A problema elegge kritikus, mert ha nincs mas megoldas Windows-t kell felraknom. (Azt pedig nagyon nem szeretnem, de hat ott nincs thread-limit, es a szervernek mennie kell...)

Elore is kosz a segitseget!

Itt a SUN mentegetodzese a thread limitrol:
-------------------

Currently, JVM on Linux cannot provide more than 1000 threads. This
is a kernel/LinuxThreads issue.
pthread library on Linux (aka LinuxThreads) uses one-to-one mapping,
meaning each thread is actually a *process*. Linux kernel has a
hard limit on how many processes can exist simultaneously (determined
at compile time). Last time I checked, this limit cannot be higher
than 4096 due to design issues. As a result, you will never be able
to have more threads than the maximum # of processes that kernel allows.
If you have a large multi-threaded application running in background,
you can create even less Java threads.
Second, prior to RedHat 7.1, pthread library on Linux uses 2M fixed
stack size for each thread. It uses virtual memory address space
3G - 1G for stacks. So you have (3G-1G)/2M = 1024. That means, you
can't have more than 1024 threads with pthread library on Linux.
Our JVM does not have its own pthread library. We use LinuxThreads
for threading support. The above two issues limit the total number
of threads you can have to around 900. (Because heap and other memory
allocation will further eat up memory address space and reduce the
max number of threads.)
We are investigating on the possibility of shipping our own pthread library
that does not rely on 1-1 mapping. No conclusion yet.
Again, this is the issue in pthread library and will not be fixed atJVM level.
xxxxx@xxxxx 2001-03-16