Resource Temporary Unavailable

Hi, we are trying to benchmark our system to see how many devices that can
be connected to our system via socket. Approximately three processes are
serving each socket connection. Somehow when we are approaching 1000
connections, the system becomes very slow, even the shell command itself. At
last we have the Resource Temporary Unavailable error, but we can’t figure
out which resource.

  1. Can anyone share with us the command to find out which resources is not
    available?
  2. Is it possible to increase the maximum number of processes that can run
    in Neutrino? We notice there is a limit on the maximum number of processes
    in Neutrino is 4096.
  3. Will it help if we change our process to thread?
  4. What are the system parameters that we must increase in order to run such
    a big loaded system?

We are using 6.30 and have plenty of memory (4GB physical and about 2GB
available during the error) and the processes have very little disk I/O. We
are using a lot of TCP/IP and UDP connections and shared memory.

Thanks,
Johannes

On Mon, 29 May 2006 08:47:06 +0700, JS wrote:

Hi, we are trying to benchmark our system to see how many devices that can
be connected to our system via socket. Approximately three processes are
serving each socket connection. Somehow when we are approaching 1000
connections, the system becomes very slow, even the shell command itself.

I can’t answer all your questions, but do make sure you are starting the
TCP/IP stack (npm-tcpip-*.so) with enough threads (one for every active
connection). Use threads_max=X. The default is 200 and we have seen Bad
Things ™ happen if you exceed that number of active connections. This
may be fixed in the latest 6.3 but it was definitely an issue in 6.2.

Rob Rutherford
Ruzz Technology

Thanks for the advise. We already doubled the threads_max in TCP/IP stack so
that we have plenty of free threads. However, we notice that as we increase
the number of socket connections, the performance has reduced quite
significantly, eventhough most of the connections are totally idle (no
sending/receiving at all) and only a few are actively sending and receiving
data. As we increase the number of idle connections, the performance of the
active connections keep on going down. Any idea why? and what shall we do to
retain the performance?

“Robert Rutherford” <mail@NoSpamPlease.ruzz.com> wrote in message
news:1jxrpegs8c9g9.nkk1yxg1a7tp$.dlg@40tude.net

On Mon, 29 May 2006 08:47:06 +0700, JS wrote:

Hi, we are trying to benchmark our system to see how many devices that
can
be connected to our system via socket. Approximately three processes are
serving each socket connection. Somehow when we are approaching 1000
connections, the system becomes very slow, even the shell command itself.

I can’t answer all your questions, but do make sure you are starting the
TCP/IP stack (npm-tcpip-*.so) with enough threads (one for every active
connection). Use threads_max=X. The default is 200 and we have seen Bad
Things ™ happen if you exceed that number of active connections. This
may be fixed in the latest 6.3 but it was definitely an issue in 6.2.

Rob Rutherford
Ruzz Technology

When we receive “Resource Temporarily Unavailable” error, how can we know
which resource is unavailable?

Is there any command that we can use to show the maximum resources allocated
in Neutrino?


“Robert Rutherford” <mail@NoSpamPlease.ruzz.com> wrote in message
news:1jxrpegs8c9g9.nkk1yxg1a7tp$.dlg@40tude.net

On Mon, 29 May 2006 08:47:06 +0700, JS wrote:

Hi, we are trying to benchmark our system to see how many devices that
can
be connected to our system via socket. Approximately three processes are
serving each socket connection. Somehow when we are approaching 1000
connections, the system becomes very slow, even the shell command itself.

I can’t answer all your questions, but do make sure you are starting the
TCP/IP stack (npm-tcpip-*.so) with enough threads (one for every active
connection). Use threads_max=X. The default is 200 and we have seen Bad
Things ™ happen if you exceed that number of active connections. This
may be fixed in the latest 6.3 but it was definitely an issue in 6.2.

Rob Rutherford
Ruzz Technology