When trying to access a controller through System Manager, I am getting the message "Too many HTML connections". Has anybody else seen this? Is there a way to determine who or what connections are connected to the filer through http or https?
I have also seen this issue on both FAS3140 and FAS3210. there are some soultions.
1. increase the max connection limit from the default 512 to 1023 by running the following commnad: options httpd.admin.max_connections 1023
If you want to see the http connections type the following: httpstat -a (if the Peak connection count is what is set on your httpd.admin.max_connections the only way to clear the connections is to do a take over and give back on the filer head).
2. last resort is to do a take over and a give back wich will clear the peak connection counter. watch the peak connection counter using httpstat -a over the next few days to make sure that the connection count doesn't grow to the max of the httpd.admin.max_connections limit.
Doing the take over and give back worked for me my peak connection counter is at 19 and hasn't gone above that for the past week.
We are seeing the same error message when attempting to connect with Oncommand (Version 2.0) to a Filer running Ontap 8.02P3:
"The maximum number of Administrative HTTP connections specified by httpd.admin.max_connections has been exceeded"
We increased the httpd.admin.max_connections to 1023 from 512 on advice from Netapp support and we now get an "Uknown" error when connecting from Oncommand.
When running an httpstat -s you can see the open HTTP connections on the Filer increasing over time until they reach < 900 and then the open counter resets and begins to increment again:
Mon Feb 13 08:39:42 GMT 2012
TOASTER1> httpstat -s
Open Peak Waits
814 1037 0
Mon Feb 13 08:47:21 GMT 2012
TOASTER1> httpstat -s
Open Peak Waits
928 1037 0
when the Open connections reach the peak and reset we also see an "NFS Down" error in DFM, although NFS is actually running on the Filer.
An "httpstat -a" shows the Errors (44450) and BadRequests (4234) counters incrementing also.
When the Filer is removed from DFM the "httpstat -a" open counter stops incrementing. We have also tried a failover and giveback of the head and the Filer could communicate with Oncommand and DFM for a short time but then the "NFS down errors" re-appeared and the httpstat open connections began incrementing again.
I've sent Netapp some packet captures from the Filer with the issue and a healthy Filer filtered on the DFM IP address as that is what appears to be flooding the Filer with invalid HTTP requests.
Netapp are analysing the packet captures and have open a Bug for this as it only seems to of started since we upgraded to 8.02P3.
Yep, I get the same exact thing. I'm running 8.1RC2 and still an issue. Whenever we want to use system manager or even Netapp Insight we shut down OnCommand for a day or so and then it starts working. Wish this would get fixed.
I'm still providing Netapp support with details of this via a Support case. From running the DFM apitest tool suggested by Netapp it looks as though the Filer intermittently fails to respond to HTTP requests or takes excessively long.
From looking at packet captures from the Filer, DFM polls the Filer forms an TCP connection and then the Filer fails to close the connection correctly which I assume is the reason that we see the excessive number of HTTP connections on the Filer?
Also had this issue since october 2011, SMVI stops working, system manager wont work, high connections shown in httpstat.
Had numerous support tickets open with various "workarounds" and "fixed in latest version of ontap" none of which have managed to stop the issue for more than a week (usually it will die after a day, an hour or so after the netapp case has been archived!!).
Been fobbed off with 526771 and 521513 during that time also.
One of my Controllers has just had this problem - I upped the max connections to 1000 and it just went up to that amount but I still could not login via Systems Manager. I have raised a case with NetApp but has anyone found a work-a-round ... some way of manually clearing down connections? I have also disabled auto discovery on the DFM server.
Unfortunately I haven't found one and I've spent a long while on this problem. My previous recommendation about AUTO-DISCOVERY didn't seem to work, we are now trying to use HTTPS as the transport instead of HTTP (stay tuned regarding that). I opened a case as well, and their response was to reboot the filer (yeah right).