[opensuse] openSUSE 11.1 x86_64 on a 512MB RAM system
Hi all,
I've stumbled on a problem, on a test machine, using openSUSE 11.1
x86_64 system with 512MB of RAM. This test was just to confirm a friends
claim that he was unable to get a working server with that kind of hardware.
The problem is that openSUSE uses all of the memory for simple
tasks, like fsck. Just as an example, here is an strace of a fsck.vfat
on a filesystem. For this I just left the system with 90MB free memory
before I ran this command:
2090 execve("/sbin/fsck.vfat", ["fsck.vfat", "/dev/sdb1"], [/* 20 vars
*/]) = 0
2090 brk(0) = 0x60f000
2090 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f093726f000
2090 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f093726e000
2090 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
2090 open("/etc/ld.so.cache", O_RDONLY) = 3
2090 fstat(3, {st_mode=S_IFREG|0644, st_size=32722, ...}) = 0
2090 mmap(NULL, 32722, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0937266000
2090 close(3) = 0
2090 open("/lib64/libc.so.6", O_RDONLY) = 3
2090 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\346\1\0\0\0\0\0"...,
832) = 832
2090 fstat(3, {st_mode=S_IFREG|0755, st_size=1406248, ...}) = 0
2090 mmap(NULL, 3506872, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0936cfa000
2090 fadvise64(3, 0, 3506872, POSIX_FADV_WILLNEED) = 0
2090 mprotect(0x7f0936e49000, 2097152, PROT_NONE) = 0
2090 mmap(0x7f0937049000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000) = 0x7f0937049000
2090 mmap(0x7f093704e000, 17080, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f093704e000
2090 close(3) = 0
2090 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f0937265000
2090 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f0937264000
2090 arch_prctl(ARCH_SET_FS, 0x7f09372646f0) = 0
2090 open("/dev/urandom", O_RDONLY) = 3
2090 read(3, "\25\v\205\210\266\247\351\223", 8) = 8
2090 close(3) = 0
2090 mprotect(0x7f0937049000, 16384, PROT_READ) = 0
2090 mprotect(0x60b000, 4096, PROT_READ) = 0
2090 mprotect(0x7f0937270000, 4096, PROT_READ) = 0
2090 munmap(0x7f0937266000, 32722) = 0
2090 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0
2090 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
2090 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f093726d000
2090 write(1, "dosfsck 2.11, 12 Mar 2005, FAT32"..., 38) = 38
2090 open("/dev/sdb1", O_RDONLY) = 3
2090 fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0
2090 lseek(3, 0, SEEK_SET) = 0
2090 read(3, "\353X\220mkdosfs\0\0\2
\0\2\0\0\0\0\370\0\0?\0\377\0\0\0\0\0"..., 512) = 512
2090 lseek(3, 160039240192, SEEK_SET) = 160039240192
2090 brk(0) = 0x60f000
2090 brk(0x630000) = 0x630000
2090 read(3, "\353R\220NTFS
\0\2\10\0\0\0\0\0\0\0\370\0\0?\0\377\0?\0\0\0"..., 512) = 512
2090 lseek(3, 3072, SEEK_SET) = 3072
2090 read(3, "\353X\220mkdosfs\0\0\2
\0\2\0\0\0\0\370\0\0?\0\377\0\0\0\0\0"..., 512) = 512
2090 lseek(3, 512, SEEK_SET) = 512
2090 read(3,
"RRaA\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512)
= 512
2090 mmap(NULL, 39055360, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f09347bb000
2090 lseek(3, 16384, SEEK_SET) = 16384
2090 read(3,
"\370\377\377\17\377\377\377\17\370\377\377\17\377\377\377\17\211\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
39053012) = 39053012
2090 mmap(NULL, 39055360, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f093227c000
2090 lseek(3, 39069696, SEEK_SET) = 39069696
2090 read(3,
Rui Santos wrote:
The latest SIGKILL was generated by ooom-kill. Linux kernel kills the process in order to get memory. There were no programs running, as this command was issued under init 1 The system has no SWAP
I'm running an 11.0 32bit system in only 512Mb, but not without swap. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-01-06 at 11:16 -0000, Rui Santos wrote:
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
The problem is that openSUSE uses all of the memory for simple tasks, like fsck. Just as an example, here is an strace of a fsck.vfat on a filesystem. For this I just left the system with 90MB free memory before I ran this command:
2090 execve("/sbin/fsck.vfat", ["fsck.vfat", "/dev/sdb1"], [/* 20 vars */]) = 0
...
2090 lseek(3, 39069696, SEEK_SET) = 39069696 2090 read(3,
2090 +++ killed by SIGKILL +++
:-)
The latest SIGKILL was generated by ooom-kill. Linux kernel kills the process in order to get memory. There were no programs running, as this command was issued under init 1 The system has no SWAP
It is known. If you check up the fsck script run at boot, you will see that it activates swap before running the fsck. You need swap with so "little" memory. Linux is memory hungry, and some programs even more so. Look, /etc/init.d/boot.rootfsck: start) # # fsck may need a huge amount of memory, so make sure, it is there. # echo "Activating swap-devices in /etc/fstab..." swapon -ae &> /dev/null rc_status -v1 -r See the comment? And with 64bits, it is worse. Just consider, that a program assigns a long int... if it was 32 bits, now it is double that, 64 bits. If the programmers are not carefull, compiling for 64 bits might end with using double memory }:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljTLAACgkQtTMYHG2NR9WvmQCfZvI8w4LT4BgRSbG74Ea09c25 N+wAoItgsRFh+07qmeYXY6MKRrQ3Dkf0 =6ShC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 06 January 2009 12:16:52 Rui Santos wrote:
If you check the final two mmap's, fsck maps 80MB of memory just to check a simple vfat filesystem. What is this ?! 80 MB. I used to run a full system on this, including fsck's. As I stated, this is just an example. Numerous other programs take a lot of memory making a system with 512MB of RAM almost unusable. Even so with a 1GB of RAM ooo-kill is sometimes called to free up RAM.
A 64 bit OS will use more memory than a 32 bit OS, it's a fact of life. Having said that, some fscks are better than others. ext2/3 for example is notoriously bad, and with very large file systems it can run out of memory even if you have 16GB or more in the system (it's one of the things said to be fixed in ext4) I don't use vfat much, so I don't know how it behaves, but it seems to have similar problems. Other file systems, such as reiserfs and xfs, have fsck programs that handle memory better As for when the OO killer is called, it all depends on what you are running on the system. If you don't have swap enabled, the system can't hide away unused RAM, so everything is forced to always be present. That is obviously a drawback on memory starved systems. Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
On Tuesday, 2009-01-06 at 11:16 -0000, Rui Santos wrote:
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
The problem is that openSUSE uses all of the memory for simple tasks, like fsck. Just as an example, here is an strace of a fsck.vfat on a filesystem. For this I just left the system with 90MB free memory before I ran this command:
2090 execve("/sbin/fsck.vfat", ["fsck.vfat", "/dev/sdb1"], [/* 20 vars */]) = 0
...
2090 lseek(3, 39069696, SEEK_SET) = 39069696 2090 read(3,
2090 +++ killed by SIGKILL +++ :-)
The latest SIGKILL was generated by ooom-kill. Linux kernel kills the process in order to get memory. There were no programs running, as this command was issued under init 1 The system has no SWAP
It is known.
If you check up the fsck script run at boot, you will see that it activates swap before running the fsck. You need swap with so "little" memory. Linux is memory hungry, and some programs even more so.
Look, /etc/init.d/boot.rootfsck:
start) # # fsck may need a huge amount of memory, so make sure, it is there. # echo "Activating swap-devices in /etc/fstab..." swapon -ae &> /dev/null rc_status -v1 -r
See the comment?
And with 64bits, it is worse. Just consider, that a program assigns a long int... if it was 32 bits, now it is double that, 64 bits. If the programmers are not carefull, compiling for 64 bits might end with using double memory }:-)
So... you're saying that the problem may be that some programs may be more memory hungry than others, witch can have worst results on a 64 bits OS. So this mau be a general Linux issue, and not openSUSE specific. Man, It never crossed my mind I would need 512MB of RAM to perform a file system check on a 850MB worth of files on a 100GB vfat file system. Gee, this is really, really scary... Thanks for your reply Carlos,
-- Cheers, Carlos E. R.
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 06 January 2009 14:47:02 Rui Santos wrote:
So... you're saying that the problem may be that some programs may be more memory hungry than others, witch can have worst results on a 64 bits OS. So this mau be a general Linux issue, and not openSUSE specific.
It's a general computing issue. It has nothing to do with linux in any way. A 64 bit value consumes twice as much space as a 32 bit value.
Man, It never crossed my mind I would need 512MB of RAM to perform a file system check on a 850MB worth of files on a 100GB vfat file system.
You didn't. You said you left 90MB free for the fsck, and without swap, that's all you're going to get. Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
On Tuesday 06 January 2009 12:16:52 Rui Santos wrote:
If you check the final two mmap's, fsck maps 80MB of memory just to check a simple vfat filesystem. What is this ?! 80 MB. I used to run a full system on this, including fsck's. As I stated, this is just an example. Numerous other programs take a lot of memory making a system with 512MB of RAM almost unusable. Even so with a 1GB of RAM ooo-kill is sometimes called to free up RAM.
A 64 bit OS will use more memory than a 32 bit OS, it's a fact of life.
Having said that, some fscks are better than others. ext2/3 for example is notoriously bad, and with very large file systems it can run out of memory even if you have 16GB or more in the system (it's one of the things said to be fixed in ext4)
I don't use vfat much, so I don't know how it behaves, but it seems to have similar problems. Other file systems, such as reiserfs and xfs, have fsck programs that handle memory better
As for when the OO killer is called, it all depends on what you are running on the system. If you don't have swap enabled, the system can't hide away unused RAM, so everything is forced to always be present. That is obviously a drawback on memory starved systems.
Thanks for the info Anders. Well... ext4 could be a solution :)
Anders
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-01-06 at 14:00 -0000, Rui Santos wrote:
Thanks for the info Anders. Well... ext4 could be a solution :)
Ha! No, the real solution is to add swap, even if you don't like the idea. That system of yours is scarce on memory, and memory hjungry, it will hit the ceiling if not for one reason for another. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljZ3QACgkQtTMYHG2NR9UQtwCfdjbxfQ+whf06VP4h3Kl8yF3k 6wYAniszc9HKhcgR0Zv0dYZRGopu7kTw =Gyf8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
On Tuesday 06 January 2009 14:47:02 Rui Santos wrote:
So... you're saying that the problem may be that some programs may be more memory hungry than others, witch can have worst results on a 64 bits OS. So this mau be a general Linux issue, and not openSUSE specific.
It's a general computing issue. It has nothing to do with linux in any way. A 64 bit value consumes twice as much space as a 32 bit value.
Man, It never crossed my mind I would need 512MB of RAM to perform a file system check on a 850MB worth of files on a 100GB vfat file system.
You didn't. You said you left 90MB free for the fsck, and without swap, that's all you're going to get.
I know I didn't. That was because I thought 90MB would more than enough. Here is a full mmap list that is executed with all 512MB available: 3922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c58613000 3922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c58612000 3922 mmap(NULL, 32722, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7c5860a000 3922 mmap(NULL, 3506872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7c5809e000 3922 mmap(0x7f7c583ed000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000) = 0x7f7c583ed000 3922 mmap(0x7f7c583f2000, 17080, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7c583f2000 3922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c58609000 3922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c58608000 3922 munmap(0x7f7c5860a000, 32722) = 0 3922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c58611000 3922 mmap(NULL, 39055360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c55b5f000 3922 mmap(NULL, 39055360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c53620000 3922 mmap(NULL, 312426496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c40c2c000 3922 munmap(0x7f7c55b5f000, 39055360) = 0 3922 munmap(0x7f7c53620000, 39055360) = 0 3922 munmap(0x7f7c40c2c000, 312426496) = 0 It uses almost 400MB of memory. Also just to correct, the files ystem is 250GB with 35000 files summing up to 825MB of files. If this is a known issue ? Using 400MB of RAM to check this kind of filesystem ? If it is, then my original question is answered.
Anders
Rui -- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rui Santos wrote:
Hi all,
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
That is strange. Right now, I have a working 11.0 server on an AMD K6-2 450 w/256 meg. (using a text desktop). 08:40 fax~> free -tm total used free shared buffers cached Mem: 250 231 19 0 52 133 -/+ buffers/cache: 44 205 Swap: 1035 3 1031 Total: 1285 234 1051 As you can see, the kernel and running applications take a core 44 meg to run. IceWM adds less than 10 meg to that. 08:40 fax~> sudo hwinfo --cpu 01: None 00.0: 10103 CPU [Created at cpu.301] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 5.8.12 "AMD-K6(tm) 3D processor" Features: fpu,vme,de,pse,tsc,msr,cx8,pge,mmx,syscall,3dnow,k6_mtrr,up Clock: 450 MHz BogoMips: 903.71 Cache: 64 kb Config Status: cfg=new, avail=yes, need=no, active=unknown Mind you, this isn't the fastest box on earth, but plenty fast enough for a hylafax fax server. If I want a gui, I just run icewm. In addition to hylafax, I have the following services running: 08:44 fax~> chkconfig --list | grep on acpid 0:off 1:off 2:on 3:on 4:off 5:on 6:off alsasound 0:off 1:off 2:on 3:on 4:off 5:on 6:off auditd 0:off 1:off 2:off 3:on 4:off 5:on 6:off avahi-daemon 0:off 1:off 2:off 3:on 4:off 5:on 6:off avahi-dnsconfd 0:off 1:off 2:off 3:on 4:off 5:on 6:off consolekit 0:off 1:off 2:on 3:on 4:off 5:on 6:off cron 0:off 1:off 2:on 3:on 4:off 5:on 6:off cups 0:off 1:off 2:on 3:on 4:off 5:on 6:off dbus 0:off 1:off 2:on 3:on 4:off 5:on 6:off earlysyslog 0:off 1:off 2:off 3:off 4:off 5:on 6:off earlyxdm 0:off 1:off 2:off 3:off 4:off 5:on 6:off fbset 0:off 1:on 2:on 3:on 4:off 5:on 6:off haldaemon 0:off 1:off 2:on 3:on 4:off 5:on 6:off irq_balancer 0:off 1:on 2:on 3:on 4:off 5:on 6:off kbd 0:off 1:on 2:on 3:on 4:off 5:on 6:off S:on lm_sensors 0:off 1:off 2:on 3:on 4:off 5:on 6:off named 0:off 1:off 2:off 3:on 4:off 5:on 6:off network 0:off 1:off 2:on 3:on 4:off 5:on 6:off nscd 0:off 1:off 2:off 3:on 4:off 5:on 6:off portmap 0:off 1:off 2:off 3:on 4:off 5:on 6:off postfix 0:off 1:off 2:off 3:on 4:off 5:on 6:off powersaved 0:off 1:off 2:on 3:on 4:off 5:on 6:off random 0:off 1:off 2:on 3:on 4:off 5:on 6:off resmgr 0:off 1:off 2:on 3:on 4:off 5:on 6:off rpmconfigcheck 0:off 1:off 2:off 3:off 4:off 5:off 6:off setserial 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on skeleton.compat 0:off 1:off 2:off 3:off 4:off 5:off 6:off smartd 0:off 1:off 2:on 3:on 4:off 5:on 6:off smbfs 0:off 1:off 2:off 3:on 4:off 5:on 6:off smpppd 0:off 1:off 2:on 3:on 4:off 5:on 6:off splash 0:off 1:on 2:on 3:on 4:off 5:on 6:off S:on splash_early 0:off 1:off 2:on 3:on 4:off 5:on 6:off sshd 0:off 1:off 2:off 3:on 4:off 5:on 6:off stopblktrace 0:off 1:on 2:on 3:on 4:off 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:off 5:on 6:off xdm 0:off 1:off 2:off 3:off 4:off 5:on 6:off So if 11.0 will run in 256meg, 11.1 should run in 512meg. (should run -- that is) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-01-06 at 13:47 -0000, Rui Santos wrote:
So... you're saying that the problem may be that some programs may be more memory hungry than others, witch can have worst results on a 64 bits OS.
Right.
So this mau be a general Linux issue, and not openSUSE specific.
A general computing problem. A 64 bit os will use more memory than a 32 bit one. And Linux has always been memory hungry, unless tuned to the contrary.
Man, It never crossed my mind I would need 512MB of RAM to perform a file system check on a 850MB worth of files on a 100GB vfat file system. Gee, this is really, really scary...
Yep, I don't know why, but it is so, at least on linux.
Thanks for your reply Carlos,
Welcome! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkljaB0ACgkQtTMYHG2NR9VKGwCXTeNNFOFRvQwT6yVrEbDwPR2P +ACfcEhCxAR0CTwYhb45BACcd2sdtYQ= =K8jy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Rui Santos wrote:
Hi all,
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
That is strange.
Right now, I have a working 11.0 server on an AMD K6-2 450 w/256 meg. (using a text desktop).
08:40 fax~> free -tm total used free shared buffers cached Mem: 250 231 19 0 52 133 -/+ buffers/cache: 44 205 Swap: 1035 3 1031 Total: 1285 234 1051
As you can see, the kernel and running applications take a core 44 meg to run. IceWM adds less than 10 meg to that.
08:40 fax~> sudo hwinfo --cpu 01: None 00.0: 10103 CPU [Created at cpu.301] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 5.8.12 "AMD-K6(tm) 3D processor" Features: fpu,vme,de,pse,tsc,msr,cx8,pge,mmx,syscall,3dnow,k6_mtrr,up Clock: 450 MHz BogoMips: 903.71 Cache: 64 kb Config Status: cfg=new, avail=yes, need=no, active=unknown
Mind you, this isn't the fastest box on earth, but plenty fast enough for a hylafax fax server. If I want a gui, I just run icewm. In addition to hylafax, I have the following services running:
08:44 fax~> chkconfig --list | grep on acpid 0:off 1:off 2:on 3:on 4:off 5:on 6:off alsasound 0:off 1:off 2:on 3:on 4:off 5:on 6:off auditd 0:off 1:off 2:off 3:on 4:off 5:on 6:off avahi-daemon 0:off 1:off 2:off 3:on 4:off 5:on 6:off avahi-dnsconfd 0:off 1:off 2:off 3:on 4:off 5:on 6:off consolekit 0:off 1:off 2:on 3:on 4:off 5:on 6:off cron 0:off 1:off 2:on 3:on 4:off 5:on 6:off cups 0:off 1:off 2:on 3:on 4:off 5:on 6:off dbus 0:off 1:off 2:on 3:on 4:off 5:on 6:off earlysyslog 0:off 1:off 2:off 3:off 4:off 5:on 6:off earlyxdm 0:off 1:off 2:off 3:off 4:off 5:on 6:off fbset 0:off 1:on 2:on 3:on 4:off 5:on 6:off haldaemon 0:off 1:off 2:on 3:on 4:off 5:on 6:off irq_balancer 0:off 1:on 2:on 3:on 4:off 5:on 6:off kbd 0:off 1:on 2:on 3:on 4:off 5:on 6:off S:on lm_sensors 0:off 1:off 2:on 3:on 4:off 5:on 6:off named 0:off 1:off 2:off 3:on 4:off 5:on 6:off network 0:off 1:off 2:on 3:on 4:off 5:on 6:off nscd 0:off 1:off 2:off 3:on 4:off 5:on 6:off portmap 0:off 1:off 2:off 3:on 4:off 5:on 6:off postfix 0:off 1:off 2:off 3:on 4:off 5:on 6:off powersaved 0:off 1:off 2:on 3:on 4:off 5:on 6:off random 0:off 1:off 2:on 3:on 4:off 5:on 6:off resmgr 0:off 1:off 2:on 3:on 4:off 5:on 6:off rpmconfigcheck 0:off 1:off 2:off 3:off 4:off 5:off 6:off setserial 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on skeleton.compat 0:off 1:off 2:off 3:off 4:off 5:off 6:off smartd 0:off 1:off 2:on 3:on 4:off 5:on 6:off smbfs 0:off 1:off 2:off 3:on 4:off 5:on 6:off smpppd 0:off 1:off 2:on 3:on 4:off 5:on 6:off splash 0:off 1:on 2:on 3:on 4:off 5:on 6:off S:on splash_early 0:off 1:off 2:on 3:on 4:off 5:on 6:off sshd 0:off 1:off 2:off 3:on 4:off 5:on 6:off stopblktrace 0:off 1:on 2:on 3:on 4:off 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:off 5:on 6:off xdm 0:off 1:off 2:off 3:off 4:off 5:on 6:off
So if 11.0 will run in 256meg, 11.1 should run in 512meg. (should run -- that is)
I also run a 64 bits openSUSE-11.0 with 256MB if RAM on a virtual machine but, like you, I use swap. Swap is sometimes used as it shows on your free command. That just makes Carlos statement more valid. -- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-01-06 at 14:00 -0000, Rui Santos wrote:
Thanks for the info Anders. Well... ext4 could be a solution :)
Ha! No, the real solution is to add swap, even if you don't like the idea. That system of yours is scarce on memory, and memory hjungry, it will hit the ceiling if not for one reason for another.
Rui said he forced the situation (fsck being oom killed) by only leaving 90Mb of free memory - I'm not sure what the purpose of that was. I've just installed an 11.1 system myself, although on 32bit hardware. In init level 1, only some 33M of memory is used, and I have no problems booting up and fscking without swap. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2009-01-06 at 14:00 -0000, Rui Santos wrote:
Thanks for the info Anders. Well... ext4 could be a solution :)
Ha! No, the real solution is to add swap, even if you don't like the idea. That system of yours is scarce on memory, and memory hjungry, it will hit the ceiling if not for one reason for another.
Rui said he forced the situation (fsck being oom killed) by only leaving 90Mb of free memory - I'm not sure what the purpose of that was.
The purpose was that a few applications were crashing randomly, and fsck was one of them. Since I thought 90 MB was far more than enough to complete the operation, it was what I did... Remember that the fsck is on a vfat file system. If you want to reproduce it, build a 250GB vfat file system with 35000 files with 850MB and try it. As I also stated in other email of this thread, I have a openSUSE 11.0 x86_64 with 256MB of RAM that does not crash ( mainly for rsyncd ).I was just trying to identify a BUG that, it isn't.
I've just installed an 11.1 system myself, although on 32bit hardware. In init level 1, only some 33M of memory is used, and I have no problems booting up and fscking without swap.
/Per
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rui Santos wrote:
Hi all,
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
I can run 11.1 with KDE on a 512Mb laptop without swap. Idling it uses about 330M RAM. A 64bit system would use roughly twice that, which obviously wouldn't work without swap. I think your fsck memory issue is filesystem-specific, but vfat isn't exactly the most popular linux filesystem, so a bugreport might not get a lot of attention. Second - what's the real purpose of trying to run 64bit openSUSE 11.1 on a tiny server with only 512M RAM? With that amount of RAM, I would not bother with 64bit openSUSE - any performance gains will be negligible if even measurable. Just run the 32bit version instead, and your server will be fine. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rui Santos wrote:
Per Jessen wrote:
Rui said he forced the situation (fsck being oom killed) by only leaving 90Mb of free memory - I'm not sure what the purpose of that was.
The purpose was that a few applications were crashing randomly, and fsck was one of them. Since I thought 90 MB was far more than enough to complete the operation, it was what I did...
Okay, I understand.
Remember that the fsck is on a vfat file system. If you want to reproduce it, build a 250GB vfat file system with 35000 files with 850MB and try it. As I also stated in other email of this thread, I have a openSUSE 11.0 x86_64 with 256MB of RAM that does not crash ( mainly for rsyncd ).I was just trying to identify a BUG that, it isn't.
Sorry, I missed that. Well, it sounds like a filesystem problem to me - it's interesting that there would be such an enormous difference in fsck though. I wouldn't expect many developments in vfat, are the two fsck versions the same? /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen escribió:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays... -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Cristian Rodríguez wrote:
Per Jessen escribió:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays...
Yeah, that's true too. I just thought Rui had some specific purpose for only having 512Mb RAM. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Rui Santos wrote:
Hi all,
I've stumbled on a problem, on a test machine, using openSUSE 11.1 x86_64 system with 512MB of RAM. This test was just to confirm a friends claim that he was unable to get a working server with that kind of hardware.
I can run 11.1 with KDE on a 512Mb laptop without swap. Idling it uses about 330M RAM. A 64bit system would use roughly twice that, which obviously wouldn't work without swap.
I think your fsck memory issue is filesystem-specific, but vfat isn't exactly the most popular linux filesystem, so a bugreport might not get a lot of attention.
Second - what's the real purpose of trying to run 64bit openSUSE 11.1 on a tiny server with only 512M RAM?
The purpose was to use x86_64 kernel and native 64bits apps, since the CPU is a 64bits one.
With that amount of RAM, I would not bother with 64bit openSUSE - any performance gains will be negligible if even measurable. Just run the 32bit version instead, and your server will be fine.
That is what I'm starting to consider... The only drawback is not to use 2TB+ file systems "transparently"... But installing a 32 bits system on that machine is starting to look a good idea.
/Per
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Cristian Rodríguez wrote:
Per Jessen escribió:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays...
Yeah, that's true too. I just thought Rui had some specific purpose for only having 512Mb RAM.
Well... the purpose is the cost and power usage. However an extra 512MB or 1.5GB is not a showstopper. What would really be a showstopper was to buy extra RAM to get the same performance just to use 64bits architecture. I also found contradicting information on 64bits vs 32 bits. Bottom line, if I can get a performance boost of 10-20% just for running 64bits, I'll go for it. Does anyone has any Knowledge/experience on switching from 32bits to 64bits ? It would also be nice to take advantage of the Execute Disable Bit without using PAE Kernel.
/Per
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-01-06 at 12:40 -0300, Cristian Rodríguez wrote:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays...
Provided you can find the particular type of memory that machine uses. Sometimes you simply can't. Or you have other constraints, like power, size... whatever; but then a 32 bit cpu would be better. There are too many variables to consider. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljjF8ACgkQtTMYHG2NR9XdwQCggwya+V0yJzl7ZrVpWjOcrRZo waYAn19xQIs0W7Se3qVJDBzZoVI3pNYj =VhYf -----END PGP SIGNATURE-----
Per Jessen wrote:
Rui Santos wrote:
Remember that the fsck is on a vfat file system. If you want to reproduce it, build a 250GB vfat file system with 35000 files with 850MB and try it. As I also stated in other email of this thread, I have a openSUSE 11.0 x86_64 with 256MB of RAM that does not crash ( mainly for rsyncd ).I was just trying to identify a BUG that, it isn't.
Sorry, I missed that. Well, it sounds like a filesystem problem to me - it's interesting that there would be such an enormous difference in fsck though. I wouldn't expect many developments in vfat, are the two fsck versions the same?
Both openSUSE-11.{0,1} version of dosfstools are 2.11 only changing the sub-version (119.1 and 121.23 respectively).
/Per
-- Rui Santos http://www.ruisantos.com/ Veni, vidi, Linux! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Jan 6, 2009 at 10:40 AM, Cristian Rodríguez
Per Jessen escribió:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays...
That depends. Have you priced a 256MB PC100 low density sodimm lately? Around $30 on ebay. Then, I have a laptop that has a bad RAM slot, so I'm stuck at 256MB. Runs 11.0/KDE3 just fine tho(with swap) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Jan 6, 2009 at 11:37 AM, Rui Santos
Well... the purpose is the cost and power usage. However an extra 512MB or 1.5GB is not a showstopper. What would really be a showstopper was to buy extra RAM to get the same performance just to use 64bits architecture. I also found contradicting information on 64bits vs 32 bits. Bottom line, if I can get a performance boost of 10-20% just for running 64bits, I'll go for it. Does anyone has any Knowledge/experience on switching from 32bits to 64bits ?
I run 2 machines on 64 and the rest on 32. No real issues. I want to do a 32bit install on one of the 64 bit machines just to see if my mencoder fps rates change any.
It would also be nice to take advantage of the Execute Disable Bit without using PAE Kernel.
I've had to remove the PAE kernel on several systems because of instability on 11.0. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rui Santos wrote:
What would really be a showstopper was to buy extra RAM to get the same performance just to use 64bits architecture.
There is no way around that - as a rule of thumb, a 64bit system will use up to twice the amount of RAM of the equivalent 32bit system. Every pointer and every integer is twice the size.
I also found contradicting information on 64bits vs 32bits. Bottom line, if I can get a performance boost of 10-20% just for running 64bits, I'll go for it.
Is your software CPU bound? If not, you'll never get anywhere 10%. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Cristian Rodríguez wrote:
Per Jessen escribió:
Just run the 32bit version instead, and your server will be fine.
No, just buy more ram, it is very cheap nowdays...
Well, some time ago, I discarded one of my old motherboards because I wanted to upgrade its ram, and found that a 128M stick cost far more than a 1G stick of current technology. Rui, why can't he set up a swap file under vfat? Windows has supported swap files for a long time, now, and I recall reading that there's no longer the performance hit that swap files used to suffer vs. swap partitions under linux. Simply setting up a swap file of a couple of GB should take care of these problems, though you might have to defrag the disk first to get a contiguous area for the swap. John Perry -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-01-06 at 15:16 -0000, Rui Santos wrote:
Rui said he forced the situation (fsck being oom killed) by only leaving 90Mb of free memory - I'm not sure what the purpose of that was.
The purpose was that a few applications were crashing randomly, and fsck was one of them. Since I thought 90 MB was far more than enough to complete the operation, it was what I did... Remember that the fsck is on a vfat file system. If you want to reproduce it, build a 250GB vfat file system with 35000 files with 850MB and try it. As I also stated in other email of this thread, I have a openSUSE 11.0 x86_64 with 256MB of RAM that does not crash ( mainly for rsyncd ).I was just trying to identify a BUG that, it isn't.
What would be the size of the FAT on that partition? Two copies. It would be the number of clusters times 4 bytes, no? I'm thinking that fsck holds that structure in memory to analyze it. Maybe both copies, and maybe a read copy and a write copy, so four times. Just guessing. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljumMACgkQtTMYHG2NR9XbkACfRkkg4AfYlsi/2vGj4b6im+p9 StMAnRxDe+8QQ1bMHryeZiGY6yaeVWIc =Nd+O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Anders Johansson -
Carlos E. R. -
Cristian Rodríguez -
David C. Rankin -
John E. Perry -
Larry Stotler -
Per Jessen -
Rui Santos