tom arnall wrote: > Understood, but I am doing a regex on text units which span more than one > line. Trying to process this text w' line-by-line io would be possible but, > as far as I can see, very awkward.
What about streams then? > Looking at 'top' and the 'MEM%' column, it seems to me that the system is > finally swapping, but only after allowing the perl applicationg to hog all > available memory, which then of course has everyone else swapping and > therefore grinding to a virtual halt. You application probably hogs the memory very fast. Too fast for swapout to complete before you run out of it. > What I want is for system to be > swapping mostly for just the perl application. By doing what you are currently doing, you will probably run out of memory anyway, but here is a little trick you could try. Not that it is very helpful... # sysctl -w vm.swappiness=100 $ cat /directory/with/a/lot/of/big/files/* >> /dev/null Now you should have most of your idle applications swapped out. >> # sysctl -w vm.swappiness=60 > > I tried setting it to 100, but i get an 'out of memory' error anyway. 100 can trigger swapout event earlier, but it still takes time. > The 'as' parameter, as set above, causes an 'out of memory' error when the > perl appl' runs. If I make the 'as' parameter to be very big (e.g., 2G), the > system allows the perl appl' to run but also to hog memory. The normal address space is around 3 GB on 32 bit archs, so 2 GB is not that big. Address space is quite different from physical memory available. Each application expects to have as much memory, and it is the same regardless of actual amount of physical memory. > To my way of > thinking, there should be a way to put a limit on the physical memory an > appl' is allowed to use, and to cause swap space to be used when that limit > is reached, i.e., a way to put a limit on the physical memory which the > individual application is allowed to use. Given the fact that this is not the way Linux manages memory, chances that such thing exists are rather low. I am not a kernel hacker, so I may be wrong, but this is not the way to solve your problem either way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
