Tag Info

Hot answers tagged

5

It appears that the stack memory limit is not allocated (anyway, it couldn't with unlimited stack). https://www.kernel.org/doc/Documentation/vm/overcommit-accounting says: The C language stack growth does an implicit mremap. If you want absolute guarantees and run close to the edge you MUST mmap your stack for the largest size you think you will ...


3

if you have spare memory increasing memory not working you should change the swappiness parameter. it tells the kernel how often use non physical memory (swap). check swappiness value: cat /proc/sys/vm/swappiness change the swappiness value temporary (lost on reboot) to value 10 (good value that decreases swap usage) sudo sysctl vm.swappiness=10 if you ...


3

Linux uses RAM in a different way from what other operating systems do. Rather than sitting there with unused RAM, Linux stores data that it thinks might be used in RAM-any applications may be cached here, files, etc. As a result, Linux RAM usage is higher than what is used by running applications. This extra usage is buffered to be sued by other things. ...


3

If a process is terminated the allocated memory will be set as free A memory leak can only occur while a process is running. You could use valgrind to instrument and analyze the process that are still running once your machine is booted.


2

If you add up MEM% for all the identical looking chrome processes, then you have well over 100%, which is impossible. That's because those are not, in fact, separate processes, they're threads, which share the same memory space. htop shows these by default, but see here for how to change that and get a view that will make more sense to you. Your total used ...


2

You will need to modify the vuze shell script. This shell script is actually a link to a file called azureus, vuze's previous name. Within this script change the line JAVA_ARGS="-Xmx128m" to JAVA_ARGS="-Xmx256m", for example if you want to increase the memory to 256MB. Then restart vuze


2

Try this. if you want with program name mypid=`pidof programname` ; top -p $mypid OR top -p `pidof programname`


2

Well, I do not expect a concise answer than the one available from here. What I understand about 32-bit OS is, the address is expressed in 32 bits, so at most the OS could use 2^32 = 4GB memory space The most that the process can address is 4GB. You are potentially confusing memory with address space. A process can have more memory than address space. ...


2

There are several reasons a piece of RAM would not be used by Linux: If Linux detects it as belonging to a hardware peripheral. Most computers need RAM for the display, and thus reserve some RAM for the graphics card. It's also possible for the graphics card to contain its own RAM; as graphics cards have relatively high memory requirements, they tend not ...


1

Arch Linux' kernel has the swap accounting disabled by default (cf. the kernel config file). You can enable it by booting with swapaccount=1 in your kernel cmdline (cf. the kernels Kconfig documentation.


1

The names actually match up, but sar and free don't show exactly the same fields. Your first ??? isn't kbcommit, it's shared memory, the same as Shmem from /proc/meminfo. The second row shows the memory usage if the memory used by buffers and cache was treated as free rather than used. $ free total used free shared buffers ...


1

By default, the maximal stack size is configured to be 8MB per process, but it can be changed using ulimit: Showing the default in kB: $ ulimit -s 8192 Set to unlimited: ulimit -s unlimited affecting the current shell and subshells and their child processes. (ulimit is a shell builtin command) You can show the actual stack address range in use with: ...


1

I found the solution to my problem here. The workaround: I increased the memory used to 1024M with these instructions. I set the "Maximum files opened for read/write" to a 101. I ran the application from the command line with this command: sudo bash -c 'ulimit -n 8192; sudo -u username ./azureus'


1

The issue may be due to shared memory, which isn't taken into account by many utilities because shared between several processes. You can check with the smemstat utility ("report memory usage with shared memory divided proportionally"). EDIT: A significant part of the memory can also be taken by the kernel (included in the used value of free output). Look ...


1

There's a bit of a conundrum here: valgrind can't determine whether a process leaked memory until it is finished, and at that point, the issue is moot. Also, not all software (including some common libraries) cleans up at exit, which will make it appear to leak memory.1 Although this is not something that's considered a good practice by many people, it ...



Only top voted, non community-wiki answers of a minimum length are eligible