RE: memory usage....help....
Most of the amount of used memory is all disk buffed to memory: 208584K buff. This is a normal thing and this used disk cache in memory will be freed up if an application needs it. J.W. Jones Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Thursday, April 26, 2001 11:04 AMTo: debian-isp@lists.debian.orgSubject: memory usagehelpHi: Mem "used" is more big ? Mem "free" is more little ? whats..??? thanks.no speaken englishsorry 2:05pm up 2:39, 1 user, load average: 0.00, 0.00, 0.00 55 processes: 54 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 0.1% user, 1.7% system, 0.0% nice, 98.0% idle Mem: 257744K av, 254608K used, 3136K free, 19252K shrd, 208584K buff Swap: 530104K av, 0K used, 530104K free 14764K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 1307 root 4 0 552 552 452 S 0 1.1 0.2 0:03 syslogd 1545 root 15 0 860 860 668 R 0 0.7 0.3 0:04 top 1 root 0 0 380 380 308 S 0 0.0 0.1 0:37 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kpiod 5 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 6 root -20 -20 0 0 0 SW< 0 0.0 0.0 0:00 mdrecoveryd 462 root 0 0 620 620 512 S 0 0.0 0.2 0:00 crond 476 root 0 0 488 488 416 S 0 0.0 0.1 0:00 inetd 485 named 0 0 1712 1712 924 S 0 0.0 0.6 0:00 named 487 named 0 0 1708 1708 920 S 0 0.0 0.6 0:00 named 561 root 0 0 652 652 436 S 0 0.0 0.2 0:00 rinetd
RE: memory usage....help....
Most of the amount of used memory is all disk buffed to memory: 208584K buff. This is a normal thing and this used disk cache in memory will be freed up if an application needs it. J.W. Jones Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 26, 2001 11:04 AMTo: [EMAIL PROTECTED]Subject: memory usagehelpHi: Mem "used" is more big ? Mem "free" is more little ? whats..??? thanks.no speaken englishsorry 2:05pm up 2:39, 1 user, load average: 0.00, 0.00, 0.00 55 processes: 54 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 0.1% user, 1.7% system, 0.0% nice, 98.0% idle Mem: 257744K av, 254608K used, 3136K free, 19252K shrd, 208584K buff Swap: 530104K av, 0K used, 530104K free 14764K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 1307 root 4 0 552 552 452 S 0 1.1 0.2 0:03 syslogd 1545 root 15 0 860 860 668 R 0 0.7 0.3 0:04 top 1 root 0 0 380 380 308 S 0 0.0 0.1 0:37 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kpiod 5 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 6 root -20 -20 0 0 0 SW< 0 0.0 0.0 0:00 mdrecoveryd 462 root 0 0 620 620 512 S 0 0.0 0.2 0:00 crond 476 root 0 0 488 488 416 S 0 0.0 0.1 0:00 inetd 485 named 0 0 1712 1712 924 S 0 0.0 0.6 0:00 named 487 named 0 0 1708 1708 920 S 0 0.0 0.6 0:00 named 561 root 0 0 652 652 436 S 0 0.0 0.2 0:00 rinetd
RE: Changing servers
>> RedHat) to a debian server. I'm trying to figure out a >> way that will cause least mail delays to our customers >> whilst the dns records propagate (The IP's are going to >> change for the mail server). >a) lower the TTLs to almost zero >b) wait $OLDTTL + $REFRESH seconds >c) change the infos >d) after checking, put the TTLs back to the normal value >That way, the change is instantaneous. You could also, if you are planning to drop the old server offline immediately upon getting the new server running properly, set this up using MX records. Set the new server's IP as a lower priority MX in the DNS files and wait for it to propagate and then drop the old server offline. The SMTP hosts on the other end *should* then automatically switch to the lower priority MX record when they see that the normal MX host is unreachable and start sending to it. You can then at your leisure set your DNS files to the proper MX and let them propagate as normal with no interruption in service. Good luck!
RE: Changing servers
>> RedHat) to a debian server. I'm trying to figure out a >> way that will cause least mail delays to our customers >> whilst the dns records propagate (The IP's are going to >> change for the mail server). >a) lower the TTLs to almost zero >b) wait $OLDTTL + $REFRESH seconds >c) change the infos >d) after checking, put the TTLs back to the normal value >That way, the change is instantaneous. You could also, if you are planning to drop the old server offline immediately upon getting the new server running properly, set this up using MX records. Set the new server's IP as a lower priority MX in the DNS files and wait for it to propagate and then drop the old server offline. The SMTP hosts on the other end *should* then automatically switch to the lower priority MX record when they see that the normal MX host is unreachable and start sending to it. You can then at your leisure set your DNS files to the proper MX and let them propagate as normal with no interruption in service. Good luck! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
