# Lots of Wired memory usage



## frijsdijk (Oct 3, 2013)

Hi,

Please observe `top` output:


```
last pid: 57990;  load averages:  0.59, 0.52, 0.44 up 9+02:49:38  18:01:09
49 processes:  1 running, 48 sleeping
CPU:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 14G Active, 6295M Inact, 9826M Wired, 460M Cache, 3284M Buf, 657M Free
Swap: 12G Total, 1559M Used, 10G Free, 12% Inuse

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
35412 mysql      23  20    0 17095M  9950M uwait   6  86:59  0.00% mysqld
 8568 www        96  20    0  5775M  5158M select 15  63:03  0.29% varnishd
12484 root        1  20    0   110M 84036K select  0   0:04  0.00% varnishd
 1748 _sphinx     3  20    0   229M 52804K select  4 669:57  0.00% searchd
 1632 bind       19  20    0   124M 10364K kqread 10   0:07  0.00% named
```

I've limited 
	
	



```
vfs.zfs.arc_max="4096M"
```
 in /boot/loader.conf, which works according to `vmstat -m` (plotting values in Munin) but I'm having almost 10 GB wired RAM. Is there any way to limit this?

This server (9.1R-p7 64-bit/16-core/32GB) is running the following applications/configurations:

Percona (on ZFS (on SSD), ~40 GB database), with an InnoDB buffer pool size of 16 GB, Varnish with 6 GB malloc, and the rest is not really worth mentioning (just 49 processes running). The machine is doing traffic up to 200 Mbit, mostly serving image content (Varnish in front of Nginx).

Now everything is running fine, but as time progresses, the amount of wired just keeps increasing (can't spot any leaks with `vmstat -m`), swap usage increases (seems to be swapping out inactive memory), up to 8 GB in swap. Swap activity is quite low, so it could be that that is indeed very 'inactive' memory so it's a good thing. But 8 GB is a lot - especially when it's swap. I/O load does not increase (so it looks like the swap is large, but not active).

I'm not sure where to look for data. Any suggestions? Can we limit this?

I've seen memory leaks before, and I could spot/track them with `vmstat -m`, but in this case, I see nothing there.


----------

