Tag Info

Hot answers tagged

12

As a general rule, physical access to the machine is all that's ever needed to compromise it. You are, after all, trusting that what the machine tells you is true; a person with physical access can void that trust. Consider that an attacker with physical access can theoretically do anything (including installation of hardware/firmware rootkits, etc). If the ...


9

32-bit x86 CPUs (since the Pentuim Pro) support up to 64 GiB RAM (using PAE). (The "CONFIG_HIGHMEM64G" kernel option needs to be set to actually use it). Each application can only see 4 GiB at a time (and some of that 4GiB must be used for other things, the exact amount depending on the "Memory split" kernel setting) 64-bit operating systems have some other ...


8

The man page you refer to comes from the procps version of top. But you're on an embedded system, so you have the busybox version of top. It looks like busybox top calculates %MEM as VSZ/MemTotal instead of RSS/MemTotal. The latest version of busybox calls that column %VSZ to avoid some confusion. commit log


8

You just need to understand Memory Concept As per your Output Of /proc/meminfo , You just need to Notice below things : Buffers :- A buffer is something that has yet to be "written" to disk. it represent how much portion of RAM is dedicated to cache disk block. "Cached" is similar like "Buffers", only this time it caches pages from file reading Cached ...


6

Some of the OpenSolaris 10 source code is publicly available, and yes, kmem uses a slab allocator in that release. See kmem.c, the comments describe the allocator in some detail. (Illumos uses the same allocator.) Looking at the Debugging With the Kernel Memory Allocator pages from the Oracle Solaris Modular Debugger Guide for Solaris 11 (Express), there ...


6

All your ram is accessible even with a 32bit kernel. The main difference is probably that any application cannot address more than 3gb of memory. I don't know if you really use such applications (usually databases, or graphics applications), otherwise you may ignore the problem. Please note that 64bits applications requires more memory (because registers and ...


6

The following is a really good reference: http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/. It contains a bibliography at the end of a variety of different references at different levels. If you want to know every gory detail you can go straight to the source: http://www.akkadia.org/drepper/dsohowto.pdf. (Ulrich Drepper wrote the Linux ...


5

Edit: This answer is incorrect. Though still a possible cause for oom-killer to be invoked, it is not the cause in this specific case. It looks like this is due to memory fragmentation. From the output you provided, the highest order contiguous memory block you have is a 32kb block in the normal zone. This means that if anything tries to allocate a chunk ...


5

Use tmpfs. It is usually mounted at /dev/shm with the default size 1/2 of total RAM. The advantage is, that the memory is available for general usage by system, until you place something there (it is reserved on the fly). You might want to tweak the default setting a bit though - I personally have something like the following in /etc/fstab: tmpfs /dev/shm ...


5

Your mysqld is configured to use 1,8 GB of RAM - propably due to your settings in /etc/my.cnf. This is much more than is physically available. Now in some point of time (you might install sysstat and ask sar about that) you seem to get memory requests (might be PHP, too) that use more RAM than is available - so the systems starts to swap. At the end of ...


5

If you want to look at a particular process named e.g. wing_ide, then ps a | fgrep wing_ide | fgrep -v fgrep gives you a number at the beginning of the line (in my case 29837) use this number as follows: fgrep '[heap]' /proc/29837/maps The output look like: 01d56000-07026000 rw-p 00000000 00:00 0 [heap] If you do this on a ...


4

I think the first thing you need to do is to intrigue the culprit which might have caused 31 instances of that job. Usually it could be your program being hanging at some point, you should debug and fix this problem unless you don't want your website updated successfully. For "Is there a way i can say do not start if an instance is alive", yes, there are ...


4

Since the data has to be decrypted to be usable, it will be available in an unencrypted state during runtime. You should treat it as though the provider can access the live running system at any time without your knowledge. This includes data at rest on disk, data contained in memory (such as decryption keys) and even any keystrokes you send (i.e., assume ...


4

The simplest way is to fill /tmp, assuming it is using tmpfs which is the default. Run df -k /tmp to make sure it is. To increase your (virtual) memory usage by 1 GB, run mkfile 1g /tmp/1g release it with rm /tmp/1g


4

It actually sounds like you're describing POSIX shared memory. Here is a quick pair of example programs to show how it works. On my system, the files get created in /run/shm (which is a tmpfs). Other systems use /dev/shm. Your program doesn't need to care, shm_open takes care of that. server.c: #include <errno.h> #include <fcntl.h> #include ...


4

If your operating system is aiming for POSIX compliance, you probably already have an tmpfs filesystem that you can write to at /dev/shm. $ >/dev/shm/foo $ df /dev/shm/foo Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 224088 0 224088 0% /dev/shm This may use swap, however. For a true ramdisk ...


4

You can't swapoff because the amount of swapped memory can't be overtaken by your RAM. You are getting legitimate error message. Small snippet. if (!quiet || errno == ENOMEM) 545 warn(_("%s: swapoff failed"), orig_special); 546 547 return -1; In my opinion, your workload increases your RAM demand. You are running a workload that requires ...


4

It is due to OpenVZ. You can see the limits applied in /proc/user_beancounters, and there is some explanation here: http://wiki.openvz.org/Privvmpages Although I have not had memory problems in a container, I think the suggestion here: http://www.moeding.net/archives/20-Optimizing-virtual-memory-in-OpenVZ-I.html to start by setting the stack size with ...


4

Someone suggested in your hear cgroups. Well, try to seek that direction as it can provide you with: applied to a group of task you choose (thus not system wide but neither per process) the limits are set for the group the limits are static they can enforce hard limit on memory and/or memory+swap Something like that could bring you closer to your goals: ...


4

The /proc/meminfo file contains the information you're after. It's pretty easy to parse too. This will get you the RAM and swap (in that order, unit is kB on all systems I know): awk '/^(MemTotal|SwapTotal)/{print $2}' /proc/meminfo To format it, you could do something like: printf "%s\t%d\t%d\n" $(hostname) \ $(awk ...


4

That won't work. The number of clock cycles each instruction takes to execute ( they take quite a few, not just one ) depends heavily on the exact mix of instructions that surround it, and varies by exact cpu model. You also have interrupts coming in and the kernel and other tasks having instructions executed mixed in with yours. On top of that, the ...


4

EDIT: Answer updated/corrected. Although the kernel documentation about this topic says that "Rootfs is a special instance of ramfs (or tmpfs, if that's enabled) [...]", it is in reality still a ramfs, as a short look in the code shows (rootfs is not mentioned in mm/shmem.c). Some patches (see e.g. here and here) were sent to the Linux kernel mailing list ...


3

Generally its quite bounded. Though there are two places (at least) these buffers can exist: In the kernel. Definitely bounded. FIFO is hard-coded I believe, TCP can be set in /proc/sys/kernel/tcp_wmem (and rmem), and (within the proc limits) with setsockopt SO_SNDBUF/SO_RCVBUF. See the tcp(7) manpage for details. In your app. If you're not calling write, ...


3

This page should help you. Just small program in c: #include <stdlib.h> #include <stdio.h> #include <string.h> int main(int argc, char** argv) { int max = -1; int sleep_interval = 2; int mb = 0; char* buffer; if(argc > 1) max = atoi(argv[1]); if(argc > 2) sleep_interval = atoi(argv[2]); ...


3

ps has many options for displaying and sorting details about processes. e.g. ps hax o pid k -time | head -n 1 will give you the PID of the process with the most CPU time used. See the man page for full details. The man page functions well enough as a reference but is not a tutorial - IMO your best option is to read and experiment until you understand what ...


3

Could be a lot of things. Maybe one of the programs you're running is occasionally and briefly using lots of RAM. If that's really weeks on the x-axis, you should sample at a much higher resolution (e.g. once per minute or even second) to get more information about what's going on that is causing the cache to get dropped. ps and top output (including load ...


3

Solaris 10 and older definitely use the SLAB allocator. OpenSolaris releases, OpenIndiana/SmartOS/etc Illumos based Oses and (current) Solaris 11, i.e. SunOS 5.11 based OSes are still using it. VM2, an unreleased project, might eventually replace it in a future Solaris 11 version (or not). Should you want to check is slab is still used in your Solaris ...


3

I admit that the following isn't a great answer, but I believe the 0x8048000 value is enshrined in the ELF Specification. See figures A.4, A.5 and A.6 in that doc. The System V ABI Intel 386 Architecture Supplement also standardizes on 0x8048000. See page 3-22, Figue 3-25. 0x804800 is prescribed as the low text segment address/high stack address. And ...


3

The term you're looking for is "Application checkpointing". The tools I know that can do that are CryoPID and CryoPID2. Both tools are for Linux only. I don't know a similar tool for BSD or OS X.


3

The C-library function free() can, but does not have to, return memory to the kernel. Some implementations of malloc() move the boundary between "heap" and otherwise unused address space (the "system break") via the sbrk() system call, then dole out smaller pieces of those large allocations. Without getting every smaller piece de-allocated, free() can't ...



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