ENOBUFS

[Jakes Louw]

Right, all you wizards: I get an ORA TNS 12560 with an HPUX Error 233 under heavy SQLNET load conditions. Is this, or is this not a shortage of buffer cache, and is DBC_MAX_PCT the right kernel param to modify? This is on a 64-way SuperDome NPar, with 64 GB RAM, and the param is currently set at 10% :- I thought 6.4 GB would be enough when I set up the server.....
Surely a single 100Bt Eth card can't handle that much traffic?
Or are we saying that the Oracle listener is too slow? (BTW, this seemed to be purely connections, not transactions, as DB traffic was very low, supported by low figures in Glance and Precise).
This is a 24x7 99.95% type server, so if I do modify the kernel, I must be sure that I'm doing the right thing....

[T G Manikandan]

It has nothing to do with dbc_max_pct.

check the amount of memory and swap usage.

check this doc

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065953792

[Jakes Louw]

Memory 39%, swap 11%. Most of swap traffic was in-memory pseudo-swap, and even then we were only on the numbers above.
Nope: we weren't out of memory or swap.

[T G Manikandan]

With 64 GB of RAm,I think that the server would not have much usage.

you should look at installting the latest patches for your 100 BT card

[Jakes Louw]

By the way, my feedback on that doc is stinky to say the least.....

[T G Manikandan]

It is not like that,
This problem can be stimulated during two stages

1.When the memory and swap in running low.
2.the server is busy handling client requests.

That doc explains the first state.I did not look at your 64GB statement.That is why I had to paste that doc.

As that is huge amount of RAM,it is not the problem in your case,check the second case.

[Jakes Louw]

Hi TG,
I'll look at the Eth card patches. Could be a firmware or driver issue.

[Kent Ostby]

Jakes --

What OS are you running on ?

Do you have any programs that are monitoring the DB logs ?

What is your latest patch for LAN and ARPA ?

Please post this information when you get a chance.

Best regards,

Kent M. Ostby

[T G Manikandan]

When the server is handling connections,the client request stays on queue and when the server starts responding the client sends a timeout.

The maximum number of connections is defined by tcp_conn_request_max

By default the tcp_conn_request_max is set to 20.

You can try increasing this parameter using ndd


Just do a

#ndd -get /dev/tcp tcp_conn_request_max
#ndd -set /dev/tcp tcp_conn_request_max 100

check this one

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065679258


revert on this .

[Jakes Louw]

TG, now you're cooking!
tcp_conn_requests, however, is already set to 4096.
I assume the only way to check the utilisation of the TCP connections is via nettl?

[Jakes Louw]

Sorry, Kent, didn't mean to ignore you:

HP-UX 11.11
GoldPack Dec 2001 (!!!)
We initially saw the TNS error in the sqlnet log.

[Jakes Louw]

Closure on this: we haven't seen a repeat after going June 2002 patch bundle.