High httpproxy memory usage with 9.713 and 9.714

Question

Hello, 
 I have a pair of virtual UTMs which have run for years with about 4G of RAM allocated to them. After the upgrade from 9.712 to 9.713 in Nov I noticed my swap usage climbing beyond its normal 10-15% level. The culprit was the httpproxy proces so I added about 1/2G to the VMs which returned the swap usage to about 15%. This past week I updated to 9.714 and observed the httpproxy process growing much larger driving swap usage into the 60% range. 
 The two systems run with almost identical configurations which change very little over time. Our usage patterns have not changed much either. I have not noticed anything in the release notes suggesting a significant change that should require more memory, so my suspicion at this point is that the httpproxy process has a memory leak. 
 The graph below shows 9.714 after a restart last week. Here is the current httpproxy memory/swap usage: 
 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 4776 httpprox 20 0 6202m 1.6g 3996 S 1 38.4 46:09.01 4.4g httpproxy

--Larry

Fahnoe · Answer

Yep, I noticed that as well. It looks like a memory leak & thus part of why I started this thread. 
 In my case, adding memory isn't really a good option, so I've added the following work-around to restart the process once it grows past 3GB: 
 Add to /etc/crontab-static: 
 # Kill httpproxy when it grows too large 
 03 * * * * root mem=`ps ax -o vsz,cmd|grep -v grep|grep httpproxy|awk '{print $1}'`;if [[ $mem -ge $((3*1024*1024)) ]];then kill `ps ax -o pid,cmd|grep -v grep|grep httpproxy|awk '{print $1}'`; fi 
 The process is restarted once the system notices that it's missing, which happens fairly quickly. 
 To get the changes added to the running crontab, make a change in the UI. For example, Management / Up2Date / Configuration / Pattern download interval 
 --Larry

RichBaldry · Answer

The continual increase in reported swap usage is an expected behaviour on Linux systems. 
 Swap usage is triggered as the required amount of system memory exceeds the amount of available RAM. The switch to 64-bit operation for various components, including the scan engines, in 9.713 had an impact in the amount of RAM used by those components - some data that would have used 32 bits to store now would take 64 bits. This has unavoidably increased the amount of RAM required to run UTM. So devices that previously managed to sit within the available physical RAM may now find they have to use swap space from time to time. 
 The way that the kernel consumes swap and reports on available/used space is a bit misleading here. Unlike the RAM statistic, the used swap will almost never go down. Whenever new swap space is required, the system does the 'lazy' thing and just consumes a little more of the swap partition, instead of cleaning up and reusing old space. Even if the system only needs 1Mb of swap once an hour while a reporting job runs, the used swap may go up by 1Mb every hour. Once all the unused swap space is consumed, it will start to re-use expired swap space. 
 Obviously, the swap usage will go back down again when you reboot the device. 
 As long as the available memory is not pegged at 100% as well, this swap increase is nothing to be concerned about and certainly on its own does not indicate a memory leak.

dlohnier · Answer

I had the same problem on our SG115 UTM wiht 4GB Memory inside. After a reboot it takes a longe time, 10-20 day to get the swap to 70%, really bad for the machine performance and the SSD. 
 I exchanged the SODIMM to a 8GB Module today and everything is fine. 
 And more, before and long time before also alway some level of swapping happend. 10-20%. Now, no swapping. So i can strongly recommand to upgrade to 8GB

High httpproxy memory usage with 9.713 and 9.714

Top Replies