Tom Mitchell wrote:
With smaller and smaller values, try reducing the
virtual memory limit. Something like:
ulimit -v 100000 ; yum -y update
ulimit -v 90000 ; yum -y update
ulimit -v 50000 ; yum -y update
ulimit -v 30000 ; yum -y update
.... Values are in 1024-byte increments -- you can do the math.
The idea is to have the kernel return an error to malloc() requests
larger than your physical memory limit. This can keep yum from swapping...
If the limit is too small it should (?) error out with grace.... I do
not know what the lower bound is... ;-)
Had a play with this today. I have only one outstanding update:
Updating:
docbook-utils-pdf noarch 0.6.14-11.fc8 updates 11 k
Started low on umlimit and incremented. Each time python or rpm would
have one or more of:
- memory alloc (155288 bytes) returned NULL.
- MemoryError
- /etc/selinux/targeted/contexts/files/file_contexts.local: line 5 has
invalid regex ^/lib/libglide3-v.\.so$: Memory exhausted
Result:
-30000 etc see error messages above.
-180000 loads my repos {fresh/updates/fedora}, detects update and began
to install, crapping out during the hashes
-182000 the hash marks finish but the terminal hung - ctrl-c, ctrl-z no
effect. {afterwards, further rpm/yum attempts hang - reboot to fix}
-182131 fails as above {memory alloc (207544 bytes) returned NULL.}
-182132 succeeds
-184000 the update succeeds
Multiplying the lowest succeed by 1024 gives: 186,503,168 bytes of
virtual memory given to shell, so that the update can work. Seems pretty
large {178MB}, but it fits with for eg Fedora's release note statement of:
Minimum RAM for graphical: 192MiB
Recommended RAM for graphical: 256MiB
as long as you have swap.
DaveT.
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum
