Jeremy C.'s questions

One more question about memory on Solaris 10.

A top shows me that I have 672 MB free memory :

130 processes: 126 sleeping, 2 zombie, 2 on cpu
CPU states: 95.1% idle,  3.9% user,  1.0% kernel,  0.0% iowait,  0.0% swap
Memory: 16G phys mem, 672M free mem, 2048M total swap, 2023M free swap

A vmstat shows me the same :

kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr rm s0 s1 s2   in   sy   cs us sy id
0 0 0 564744 687896  3  13  0  0  0  0  0  0  0  0  0  354  667  752  1  1 98

But when I do a prstat -a -s size I get this :

NPROC USERNAME  SWAP   RSS MEMORY      TIME  CPU
   45 orbixadm 1449M 1592M   9.7%   4:46:53 0.4%
   48 root      146M  160M   1.0%   8:09:49 1.2%
    3 user1      46M  204M   1.2%   0:00:45 0.0%
    9 webservd   46M   14M   0.1%   0:00:00 0.0%
    5 ctxsrvr    28M   32M   0.2%   4:54:51 0.0%
   11 user2      23M   34M   0.2%   0:00:37 0.2%
    4 user3    4840K   11M   0.1%   0:00:01 0.0%
    1 smmsp    1456K 4552K   0.0%   0:00:24 0.0%
    2 daemon   2128K 6224K   0.0%   0:06:32 0.0%
    1 user4    1232K 3608K   0.0%   0:00:00 0.0%
    1 nagios    376K 2472K   0.0%   0:15:18 0.0%

and as you can see, the sum of RSS values does not reach 15GB of memory, and even if I add SWAP values to it.

So my question is : which command do I believe ?

If top and vmstat give me the good result, where are my 15GB used memory ? If not, why do they show me that ?

Edit: the result for the command : % echo ::memstat | mdb -k

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                    1687138             13180   82%
Anon                       137110              1071    7%
Exec and libs               47107               368    2%
Page cache                  95277               744    5%
Free (cachelist)            22248               173    1%
Free (freelist)             69592               543    3%

Total                     2058472             16081
Physical                  2055442             16058

Edit 2:

Ok, now i can see the memory used by ARC cache.
But with some new tests, now I have :

2066 MB used (prstat -Z and echo ::memstat | mdb -k result)
1193 MB free (top result)
8859 MB ARC cache (kstat zfs::arcstats:size result)

Which give us more or less 12 GB of memory, while my system has 16 GB.
Maybe I missed something else, but where are the other 4 GB ?

I have a problem with Nagios, and in particular with the check_tcp plugin, used to check the Citrix connection on a Windows server. Nagios is in version 3.3.1 and nagios plugins are in version 1.4.15 (which seems to be the last ones).

When the connection is OK, the service's status is OK with Status Information saying : "TCP OK". But when the Citrix service is not responding, the service's status is still OK with Status Information saying : "Connection refused", which indicate clearly that the Citrix connection is not OK.

One more thing, when launching the check command by hand it returns 0, which explains the OK status on the web interface, while it must returns 1 or something else to indicate the error.

Did someone already have the same problem ? And is there something that I can do to correct this check ?

Thanks in advance,

Jeremy

On a Solaris 10 server I installed Apache2 (v2.2.20), PHP5 (v5.2.1), and all dependencies with packages from [1]: http://unixpackages.com (the new sunfreeware.com).

Now apache is running, and doesn't generate errors at startup. The probleme is when I ask the server with a browser I get an ERR_EMPTY_RESPONSE.

In logs, each time I ask the server I get this error :

child pid "PID" signal Segmentation fault (11)

It seems coming from PHP while there's no error when deactivate it in httpd.conf, but I can't find where.

[EDIT]

Using the last version of PHP available on unixpackages.com (v5.3.6) and forcing some library paths during install solved the problem. It seems that older version don't works with Apache v2.2.20.

Thanks a lot for your answers even if they weren't very helpful.