Beefy server uses swap!

LawsHosting

Verified User
Joined
Sep 13, 2008
Messages
2,372
Location
London UK
Ok, after I updated some software on a server, I thought I'd check free & top, to find some interesting, but disturbing results:

# free
total used free shared buffers cached
Mem: 8245660 6851392 1394268 0 346172 5901352
-/+ buffers/cache: 603868 7641792
Swap: 4095976 5764 4090212

# top
top - 09:54:43 up 94 days, 17:52, 1 user, load average: 0.01, 0.00, 0.00
Tasks: 278 total, 1 running, 277 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8245660k total, 6848812k used, 1396848k free, 346172k buffers
Swap: 4095976k total, 5764k used, 4090212k free, 5901296k cached
Ok, its using swap at just 90 odd days... I found out which process is using swap (O then p), and its MySQL at the top, which, for a i7 8core cpu, to me is surprising - unless my my.cnf optimisation went screw-wiff.
The server is running normal though - just that my other server (daul-core server (2gig)) used just 36292k in 701 days!

Any views?
 
Did you optimize MySQL?

Type 'mysqladmin proc stat' and see if there are some delayed insert options at some of the databases. It will also cause a bit high resource consumption.
 
I did optimise, well, from a blog source (forgot which).

Heres my mysqladmin output
Uptime: 7901392 Threads: 1 Questions: 10327700 Slow queries: 1 Opens: 229230 Flush tables: 1 Open tables: 1024 Queries per second avg: 1.307

heres my cnf file:
Code:
[mysqld]
local-infile=0
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
query-cache-type=1
character_set_server=utf8
collation_server=utf8_general_ci
long_query_time=5
key_buffer=256M
key_buffer_size=64M
table_open_cache=256
sort_buffer_size=8M
read_buffer_size=2M
read_rnd_buffer_size=4M
myisam_sort_buffer_size=64M
thread_cache_size=8
query_cache_size=32M
query_cache_limit=8M
max_allowed_packet=16M
tmp_table_size=128M
max_heap_table_size=128M
table_definition_cache=512
table_cache=1024
wait_timeout=60
connect_timeout=10
interactive_timeout=120
join_buffer_size=32M
thread_concurrency = 16
log-bin=mysql-bin
binlog_format=mixed
server-id = 1

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
#safe-updates
[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
 
I did optimise, well, from a blog source (forgot which).

Heres my mysqladmin output


heres my cnf file:
Code:
[mysqld]
local-infile=0
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
query-cache-type=1
character_set_server=utf8
collation_server=utf8_general_ci
long_query_time=5
key_buffer=256M
key_buffer_size=64M
table_open_cache=256
sort_buffer_size=8M
read_buffer_size=2M
read_rnd_buffer_size=4M
myisam_sort_buffer_size=64M
thread_cache_size=8
query_cache_size=32M
query_cache_limit=8M
max_allowed_packet=16M
tmp_table_size=128M
max_heap_table_size=128M
table_definition_cache=512
table_cache=1024
wait_timeout=60
connect_timeout=10
interactive_timeout=120
join_buffer_size=32M
thread_concurrency = 16
log-bin=mysql-bin
binlog_format=mixed
server-id = 1

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
#safe-updates
[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout

what about your sysctl config?

the actual my.cnf file wont help us without knowing the usage and needs from the DB driven scripts on your machine.
 
Last edited:
It could have been a one time thing that used up a lot of memory and caused swapping. Swap does not clear out very fast. To really test it I would reboot which will clear the swap and see if it starts building again.

You can also do:

Code:
swapoff /dev/sdxxx
swapon /dev/sdxxx

This will be a lot faster than rebooting but if information is currently being used the outcome could be unpredictable.

Regardless of how you clear the swap I believe that is what needs to be done first in order to find out if this is an ongoing problem.
 
Back
Top