Maximum number of Java Thread


New Member
Hi members,​

Please need your help if you know that we have a server in strato Linux V80-49 (1.en)

We are getting "out of memory" exception from our application while creating the maximum​
number of Java Thread. Please see the below exception log. We would require approximate​
45000 concurrent Thread running for our application testing. Could you please check the​
issue and let us know the findings.​
java.lang.OutOfMemoryError: unable to create new native thread​ No buffer space available​
Thanks and look forward to your immediate help...​
Last edited:


He who dances with pointers
Who did write that application? If you did so please do the usual: profile the memory footprint.
We don't even have remotely the knowledge you do about your application.

If it's an application from somebody else: you might want to tell us what software you're talking about, at the moment we're basically blind folded.
And yes, it could be the server but once again: you will know long before we have a chance to even know.


Active Member
also have a look on the ulimits of the os/user and the memory-configuration of the java-process.

.... but yes, more infos are needed.


New Member

Thank you guys for your reply

I have applied whatever you have mentioned but it shows Permission denied.

root@h2822796:~# cat /proc/sys/vm/max_map_count
root@h2822796:~# echo 262144 > /proc/sys/vm/max_map_count
-bash: /proc/sys/vm/max_map_count: Permission denied

Even the system refused to change ulimits of the os/user and the memory config of the java process..

Please help us if you have any alternatives way to resolve issues.
Last edited:


New Member
Hi Marce...

Thank you for immediate reply.

Any suggestion you can provide us based on our VPS from that we can migrate from Virtuozzo environment to recommended platforms like KVM or Vmware-based Virtualisation....
Last edited:


Active Member
I don't know if strato supports mirgration of virtuozzo to kvm or vmware - maybe you need to ask the off. support here.

"standard-solution" would be: order a new vm, migrate your services, konfiguration and data and throw away the old vm.