Hi !
Ananda Kumar wrote:
Hi All,
I have setup slave db. The machine configuration details of this slave is
same as master.
OS=redhat
8 cpu
16GB RAM
key_buffer_size=3000M
innodb_buffer_pool_size=10000M.
But when i do top, in the master db
Cpu(s): 0.5%us, 0.3%sy, 0.0%ni, 87.2%id, 11.9%wa, 0.0%hi, 0.1%si,
0.0%st
Mem: 16436956k total, 16350252k used, 86704k free, 9188k buffers
Swap: 16386292k total, 37232k used, 16349060k free, 2358944k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28706 mysql 15 0 14.3g 13g 4688 S 6 84.1 540:21.55 mysqld
On slave db
Cpu(s): 0.7%us, 0.2%sy, 0.0%ni, 87.3%id, 11.8%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 16436956k total, 16351536k used, 85420k free, 16400k buffers
Swap: 16386292k total, 164k used, 16386128k free, 4289520k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14042 mysql 18 0 14.0g 11g 4652 S 7 72.5 265:08.62 mysqld
435 root 10 -5 0 0 0 S 0 0.0 3:29.07 kswapd0
As you can see the RES in master is 13g, but on slave its 11G any specific
reason for this. This is causing some of the sql's on the slave to be
slower than master for the same select statement on both master and slave.
"RES" is the amount of RAM used by the process, as controlled by the
memory allocation (Linux kernel).
It depends not only on the address space requested by the process, but
also on those by other processes and on the paging / swapping policy
(which AFAIK depends on the which process accesses memory how frequent).
The MySQL process on the slave has a smaller RES if and only if there is
reason for the Linux kernel to allocate less RAM, this typically means
there are other processes requiring it more urgently.
*If* the database load on the master is higher, or accesses more data,
or there is less competition about the RAM, it is only natural that RES
for the slave is less.
Database performance strongly depends on caching:
If the cache on the master already contains the needed pages, and on the
slave it doesn't, it is normal that the first statement needing them has
to wait for disk I/O and so is slower.
Jörg
--
Joerg Bruehe, MySQL Build Team, [EMAIL PROTECTED]
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
