@BORJAMAR: "Hello,
I've been doing a test with today's FreeBSD-current, amd64.
I've set up a website serving files from a NFS backend. The activity  
is quite high (the machine has reached 40 Mbps), and I've configured  
a stripping two disks ZFS filesystem as well, as I intended to do  
some more tests.
However, I have a network problem:
Sep 19 17:16:18 server kernel: TCP: [X.Y.Z.T]:14301 to [A.B.C.D]:80;  
syncache_socket: Socket create failed due to limits or memory shortage
Sep 19 17:16:18 server kernel: TCP: [X.Y.Z.T]:14301 to [A.B.C.D]:80  
tcpflags 0x18<PUSH,ACK>; tcp_input: Listen socket: Socket allocation  
failed due to limits or memory shortage, sending RST
These are not innocuous messages, the machine is rejecting  
connections like crazy. Any ideas?
The number of established TCP connections was around 490, and the  
machine has 2 GB of RAM.
Thanks in advance,
Borja.
"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."
    Douglas Adams, "Mostly Harmless"
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @BORJAMAR: "<quote>
It's the first thing I thought, and I cranked it to a very high value  
just in case:
vm.kmem_size_max: 1073741824
It didn't help. Any ideas? The ZFS filesystem was mounted but it had  
absolutely no activity at that
point. It was just Apache 2.2 serving files coming from a NFS-mounted  
filesystem.
Borja.
"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."
    Douglas Adams, "Mostly Harmless"
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @kris: "<quote>
You actually wanted to tune vm.kmem_size too or it may not actually 
change the value used (_max is just a ceiling for autotuning).  However 
if this is i386 you can't set it that high without also adjusting 
KVA_PAGES too (which has other effects).
Kris
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @BORJAMAR: "<quote>
It's an amd64. I understand that i386 is mostly out of the question  
if I want to play reasonably safe with ZFS :)
Oh, ok. I will try with both, then. Should I try the same value?  
Perhaps it's a bit high, but I understand that with a 64 bit address  
space I can set it sort of arbitrarily high without many side effects.
Thank you very much,
Borja.
"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."
    Douglas Adams, "Mostly Harmless"
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @BORJAMAR: "I've just tried cranking up both vm.kmem_size and vm.kmem_size_max to  
the same value (1073741824), and I end up with
the same problem.
In order to have a repeatable load I'm using httperf hog num- 
conn=100000 rate 600 timeout 5
retrieving a small jpg file.
The ESTABLISHED TCP sessions I see at the victim machine peak at  
about 800, and I start to see the same "memory allocation" messages  
in /var/log/messages.
I'm clueless, I must admit :/ Just in case it was the problem I've  
set up kern.ipc.somaxconn to 4096, but the result is still the same.  
And disabled syncookies as well.
I'm looking at the whole sysctl variables tree and I cannot see a  
clue. Just to refresh it, it's -CURRENT from yesterday, amd64,  
apache22 compiled from ports.
I've just tried using the echo service from inetd, and the server is  
keeping 1024 established
connections without that error. I just don't understand why this can  
fail with Apache, but it seems it's an issue with -current, as we  
have a similar setup with 6.2(i386), same hardware, and it works.
Any ideas? So far I'm getting lost :/
Borja.
<quote>
"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."
    Douglas Adams, "Mostly Harmless"
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @BORJAMAR: "<quote>
Here's what I've found out. Apache was confgured by a different  
person, and I didn't notice that the MaxClients parameter was set too  
low (159).
Setting it up to a high value (1024) has made those errors disappear.  
So that "memory limit" was actually that the system was dropping  
connection requests from the listen queue. The error message is quite  
looks misleading to me. At least I had never seen it, so it caught me  
by surprise.
Sorry about the confusion. I will go on doing tests and let you know  
the result.
Borja.
"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."
    Douglas Adams, "Mostly Harmless"
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @kris: "<quote>
Yes, you should set them both to the same value.
Kris
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @kometen: "<quote>
Thank you. I was planning to upgrade our file/samba server with
current from June 11'th next week to get the latest enhancements
related to zfs. And with 5 TB in use the last thing I needed was
dropped connections. :-)
regards
Claus
When lenity and cruelty play for a kingdom,
the gentlest gamester is the soonest winner.
Shakespeare
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>"
Posted automagically by a mail2news austin25@example.org e.V.
Please direct questions, flames, donations, etc. to <email_address>"
{'source': 'USENET', 'other_information': '{"reply_count": 7, "forum_name": "muc.lists.freebsd.current.20150814.mbox"}', 'file': 'data/output/usenet-muc.lists.parquet'}