Hi to all, I installed 7zip from ports in my freebsd server. I use Freebsd to compress and backup my file. Now I have this error ERROR: Can't allocate required memory! when I try to compress my websites folder. It's about 9/10.000 files for a total of 3/4 GB. I posted in 7zip forum, and they says there is a limitation of 512 MB in RAM usage for my account. Could you help me to see if this is true? Thank you very much for your help! Leonardo

0 |

9/9/2008 6:46:23 AM

Leonardo Burchi wrote: > I posted in 7zip forum, and they says there is a limitation of 512 MB in > RAM usage for my account. > Could you help me to see if this is true? Try 'limits' to see whar toy limits are. 'man limits' for more info. Example: tingo@kg-work2$ limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 524288 kB stacksize 65536 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB HTH -- Torfinn Ingolfsen, Norway

0 |

9/9/2008 7:28:11 AM

Thank you for your reply! This is my limits output: Resource limits (current): cputime infinity secs filesize infinity kB datasize 524288 kB stacksize 65536 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB I think there is no limit in RAM usage for my account. Right? Thank you again!! Torfinn Ingolfsen ha scritto: > Leonardo Burchi wrote: >> I posted in 7zip forum, and they says there is a limitation of 512 MB >> in RAM usage for my account. >> Could you help me to see if this is true? > > Try 'limits' to see whar toy limits are. 'man limits' for more info. > Example: > > tingo@kg-work2$ limits > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 524288 kB > stacksize 65536 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked infinity kB > maxprocesses 5547 > openfiles 11095 > sbsize infinity bytes > vmemoryuse infinity kB > > HTH

0 |

9/9/2008 6:55:19 PM

Leonardo Burchi wrote: > Thank you for your reply! > This is my limits output: > > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 524288 kB > stacksize 65536 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked infinity kB > maxprocesses 5547 > openfiles 11095 > sbsize infinity bytes > vmemoryuse infinity kB > > I think there is no limit in RAM usage for my account. Right? Probably wrong, see "datasize" in your output above. This is probably covered in the handbook, but the first reference I found was this one: http://taosecurity.blogspot.com/2006/09/snort-260-high-memory-usage-on-freebsd.html Ah, see the tuning(7) man page, about the kern.maxdsiz tunable. -- Torfinn Ingolfsen, Norway

0 |

9/9/2008 7:48:29 PM

On Tue, 09 Sep 2008 20:55:19 +0200, Leonardo Burchi <bjl@freemail.it> wrote: > Torfinn Ingolfsen ha scritto: >> Leonardo Burchi wrote: >>> I posted in 7zip forum, and they says there is a limitation of 512MB >>> in RAM usage for my account. >>> >>> Could you help me to see if this is true? >> >> Try 'limits' to see whar toy limits are. 'man limits' for more info. > > This is my limits output: > > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 524288 kB > stacksize 65536 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked infinity kB > maxprocesses 5547 > openfiles 11095 > sbsize infinity bytes > vmemoryuse infinity kB > > I think there is no limit in RAM usage for my account. Right? There is an implied limit to the `data' segment of each process that is indeed set to 512MB for 32-bit programs: $ sysctl kern.maxdsiz kern.maxdsiz: 536870912 $ sysctl -d kern.maxdsiz kern.maxdsiz: max data size This is a `loader tunable', so you can set it at boot time but it is not possible to increase once the kernel has started. See loader.conf(5) for details about setting loader tunables. Having written that, I would be _very_ worried if a compression utility started taking more than 512MB of virtual memory. This is an absurd amount of memory for a utility that wants to compress a few thousands of files. The compression ratio may be better in the long run, but there are other compression tools (like gzip(1) or bzip(2) that do not require such huge amounts of memory to work).

0 |

9/9/2008 10:00:35 PM

Thank you Giorgos and thank you Torfinn. I have update my kern.maxdsiz on /boot/loader.conf to 1 GB and now all works fine! I'm perfectly agree with you Giorgos, it needs a very lot of RAM. I think I will try gzip or bzip. Thank you again!! Giorgos Keramidas ha scritto: > On Tue, 09 Sep 2008 20:55:19 +0200, Leonardo Burchi <bjl@freemail.it> wrote: >> Torfinn Ingolfsen ha scritto: >>> Leonardo Burchi wrote: >>>> I posted in 7zip forum, and they says there is a limitation of 512MB >>>> in RAM usage for my account. >>>> >>>> Could you help me to see if this is true? >>> Try 'limits' to see whar toy limits are. 'man limits' for more info. >> This is my limits output: >> >> Resource limits (current): >> cputime infinity secs >> filesize infinity kB >> datasize 524288 kB >> stacksize 65536 kB >> coredumpsize infinity kB >> memoryuse infinity kB >> memorylocked infinity kB >> maxprocesses 5547 >> openfiles 11095 >> sbsize infinity bytes >> vmemoryuse infinity kB >> >> I think there is no limit in RAM usage for my account. Right? > > There is an implied limit to the `data' segment of each process that is > indeed set to 512MB for 32-bit programs: > > $ sysctl kern.maxdsiz > kern.maxdsiz: 536870912 > $ sysctl -d kern.maxdsiz > kern.maxdsiz: max data size > > This is a `loader tunable', so you can set it at boot time but it is not > possible to increase once the kernel has started. See loader.conf(5) > for details about setting loader tunables. > > Having written that, I would be _very_ worried if a compression utility > started taking more than 512MB of virtual memory. This is an absurd > amount of memory for a utility that wants to compress a few thousands of > files. The compression ratio may be better in the long run, but there > are other compression tools (like gzip(1) or bzip(2) that do not require > such huge amounts of memory to work). >

0 |

9/10/2008 6:20:06 AM