I am trying to setup sonarqube on ec2 instance Amazon Linux AMI. on t2 micro instance. using the below sonarqube version:6.0, java:java-1.8.0-openjdk, mysql:mysql Ver 14.14 Distrib 5.6.39, for Linux (x86_64) using EditLine wrapper
after sonar start command:
sudo ./sonar.sh start
sonar is not starting. after checking in logs gives out below message.
--> Wrapper Started as Daemon
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
2018.05.16 19:30:50 INFO app[o.s.a.AppFileSystem] Cleaning or
creating temp directory /opt/sonarqube/temp
2018.05.16 19:30:50 INFO app[o.s.p.m.JavaProcessLauncher] Launch
process[es]: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-
7.b10.37.amzn1.x86_64/jre/bin/java -Djava.awt.headless=true -Xmx1G -
Xms256m -Xss256k -Djna.nosys=true -XX:+UseParNewGC -
XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -
XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -
Djava.io.tmpdir=/opt/sonarqube/temp -javaagent:/usr/lib/jvm/java-1.8.0-
openjdk-1.8.0.171-7.b10.37.amzn1.x86_64/jre/lib/management-agent.jar -
cp ./lib/common/*:./lib/search/* org.sonar.search.SearchServer
/opt/sonarqube/temp/sq-process620905092992598791properties
OpenJDK 64-Bit Server VM warning: INFO:
os::commit_memory(0x00000000c5330000, 181207040, 0) failed;
error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 181207040 bytes for
committing reserved memory.
# An error report file with more information is saved as:
# /opt/sonarqube/hs_err_pid30955.log
<-- Wrapper Stopped
Below Memory info:
/proc/meminfo:
MemTotal: 1011176 kB
MemFree: 78024 kB
MemAvailable: 55140 kB
Buffers: 8064 kB
Cached: 72360 kB
SwapCached: 0 kB
Active: 860160 kB
Inactive: 25868 kB
Active(anon): 805628 kB
Inactive(anon): 48 kB
Active(file): 54532 kB
Inactive(file): 25820 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 108 kB
Writeback: 0 kB
AnonPages: 805628 kB
Mapped: 30700 kB
Shmem: 56 kB
Slab: 28412 kB
SReclaimable: 16632 kB
SUnreclaim: 11780 kB
KernelStack: 3328 kB
PageTables: 6108 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 505588 kB
Committed_AS: 1348288 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 47104 kB
DirectMap2M: 1001472 kB
CPU:total 1 (initial active 1) (1 cores per cpu, 1 threads per core)
family 6 model 63 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3,
ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, lzcnt, tsc,
bmi1, bmi2
Have you tried to increase the maximum allowed heap size memory for your SonarQube application ?
You can do so by editing the sonar.properties file, found in your SQ installation folder.
You can follow this guide in order to configure your SQ max heap size.
Related
My code crashes with this error message
Executing "/usr/bin/java com.utils.BotFilter"
OpenJDK 64-Bit Server VM warning: INFO:
os::commit_memory(0x0000000357c80000, 2712666112, 0) failed;
error='Cannot allocate memory' (errno=12)
There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (malloc) failed to allocate 2712666112 bytes for committing reserved memory.
An error report file with more information is saved as:
/tmp/jvm-29955/hs_error.log`
Here is the content of the generated hs_error.log file:
https://pastebin.com/yqF2Yy4P
This line from crash log seems interesting to me:
Memory: 4k page, physical 98823196k(691424k free), swap 1048572k(0k free)
Does it mean that the machine has memory but is running out of swap space?
Here is meminfo from the crash log but I don't really know how to interpret it, like what is the difference between MemFree and MemAvailable? How much memory is this process taking?
/proc/meminfo:
MemTotal: 98823196 kB
MemFree: 691424 kB
MemAvailable: 2204348 kB
Buffers: 145568 kB
Cached: 2799624 kB
SwapCached: 304368 kB
Active: 81524540 kB
Inactive: 14120408 kB
Active(anon): 80936988 kB
Inactive(anon): 13139448 kB
Active(file): 587552 kB
Inactive(file): 980960 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1048572 kB
SwapFree: 0 kB
Dirty: 1332 kB
Writeback: 0 kB
AnonPages: 92395828 kB
Mapped: 120980 kB
Shmem: 1376052 kB
Slab: 594476 kB
SReclaimable: 282296 kB
SUnreclaim: 312180 kB
KernelStack: 317648 kB
PageTables: 238412 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 50460168 kB
Committed_AS: 114163748 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 314408 kB
VmallocChunk: 34308158464 kB
HardwareCorrupted: 0 kB
AnonHugePages: 50071552 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 116924 kB
DirectMap2M: 5115904 kB
DirectMap1G: 95420416 kB
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Set larger code cache with -XX:ReservedCodeCacheSize=
In case you have many contexts wars deployed on your tomcat try reduce them
As Scary Wombat mentions, the JVM is trying to allocate 2712666112 bytes (2.7 Gb) of memory, and you only have 691424000 bytes (0.69 Gb) of free physical memory and nothing available on the swap.
Another possibility (which I encountered just now) would be bad settings for "overcommit memory" on linux.
In my situation, /proc/sys/vm/overcommit_memory was set to "2" and /proc/sys/vm/overcommit_ratio to "50" , meaning "don't ever overcommit and only allow allocation of 50% of the available RAM+Swap".
That's a pretty deceptive problem, since there can be a lot of memory available, but allocations still fail for apparently no reason.
The settings can be changed to the default (overcommit in a sensible way) for now (until a restart):
echo 0 >/proc/sys/vm/overcommit_memory
... or permanently:
echo "vm.overcommit_memory=0 >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf # apply it immediately
Note: this can also partly be diagnosed by looking at the output of /proc/meminfo:
...
CommitLimit: 45329388 kB
Committed_AS: 44818080 kB
...
In the example in the question, Committed_AS is much higher than CommitLimit, indicating (together with the fact that allocations fail) that overcommit is enabled, while here both values are close together, meaning that the limit is strictly enforced.
An excellent detailed explanation of these settings and their effect (as well as when it makes sense to modify them) can be found in this pivotal blog entry. (Tl;dr: messing with overcommit is useful if you don't want critical processes to use swap)
In lib/assets directory, I ran npm install, and my package.json file in that directory have the following:
"scripts": {
"test": blah
"bundle": "./node_modules/.bin/webpack",
"lint": blah
},
so I can start webpack by calling npm run bundle or npm run bundle -- -p
How do I kill it?
Note: ps aux | grep webpack gives different pid every time:
USER PID COMMAND
my-name 85294 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn webapck
my-name 85305 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn webapck
my-name 85316 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn webapck
Something like this would work in bash:
$ ps -ef | grep webpack | awk '{print $2}' | xargs kill
It turns out that I misunderstand how webpack works.
I thought Webpack will keep running in background and compile the asset for me.
To explain why I think that way, let me start from the beginning:
I fork a rails project from GitHub (https://github.com/DMPRoadmap/roadmap), get it up and running, but I realise that it doesn't display images when I access the rails application website through browser, and its layout are not applied (stylesheets). I realise I need to use webpack to compile these asset.
So I started webpack by running npm install and npm run bundle, and the terminal show me something like this:
$ npm run bundle
> roadmap#1.0.0 bundle /Users/my-name/dev/testing/dmp-roadmap/lib/assets
> webpack
Webpack is watching the files…
Hash: 1af8780dadb3d5abe275
Version: webpack 3.11.0
Time: 7360ms
Asset Size Chunks Chunk Names
images/bournemouth_logo.png 16.1 kB [emitted]
fonts/glyphicons-halflings-regular.eot 20.1 kB [emitted]
fonts/glyphicons-halflings-regular.woff 23.4 kB [emitted]
fonts/glyphicons-halflings-regular.ttf 45.4 kB [emitted]
fonts/glyphicons-halflings-regular.svg 109 kB [emitted]
fonts/fontawesome-webfont.eot 166 kB [emitted]
fonts/fontawesome-webfont.woff2 77.2 kB [emitted]
fonts/fontawesome-webfont.woff 98 kB [emitted]
fonts/fontawesome-webfont.ttf 166 kB [emitted]
fonts/fontawesome-webfont.svg 444 kB [emitted] [big]
./stylesheets/skins/lightgray/content.inline.min.css 3.17 kB [emitted]
./stylesheets/skins/lightgray/content.min.css 3.57 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce-small.eot 9.49 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce-small.svg 24.7 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce-small.ttf 9.3 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce-small.woff 9.38 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce.eot 17.6 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce.svg 46 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce.ttf 17.4 kB [emitted]
./stylesheets/skins/lightgray/fonts/tinymce.woff 17.5 kB [emitted]
./stylesheets/skins/lightgray/img/anchor.gif 53 bytes [emitted]
./stylesheets/skins/lightgray/img/loader.gif 2.61 kB [emitted]
./stylesheets/skins/lightgray/img/object.gif 152 bytes [emitted]
./stylesheets/skins/lightgray/img/trans.gif 43 bytes [emitted]
./stylesheets/skins/lightgray/skin.min.css 40 kB [emitted]
javascripts/application.js 3.26 MB 0 [emitted] [big] application
javascripts/vendor.js 317 kB 1 [emitted] [big] vendor
stylesheets/application.css 201 kB 0 [emitted] application
images/2013_Jisc_Logo_RGB72.png 2.12 kB [emitted]
images/asc.gif 54 bytes [emitted]
images/background.jpg 1.69 kB [emitted]
images/bg.gif 64 bytes [emitted]
images/dcc_logo_white.png 3.03 kB [emitted]
images/dcc_logo.png 907 bytes [emitted]
fonts/glyphicons-halflings-regular.woff2 18 kB [emitted]
images/desc.gif 54 bytes [emitted]
images/download.png 2.55 kB [emitted]
images/fullscreen.png 341 bytes [emitted]
images/favicon.ico 1.15 kB [emitted]
images/glyphicons-halflings-white.png 8.78 kB [emitted]
images/help_button.png 557 bytes [emitted]
images/glyphicons-halflings.png 12.8 kB [emitted]
images/logo.png 15.5 kB [emitted]
images/minus_laranja.png 408 bytes [emitted]
images/lancaster_logo.png 26.2 kB [emitted]
images/lse-library_logo.png 18.2 kB [emitted]
images/plus_laranja.png 781 bytes [emitted]
images/question-mark.png 2.57 kB [emitted]
images/rails.png 6.65 kB [emitted]
images/newcastle_logo.png 142 kB [emitted]
images/remove.png 681 bytes [emitted]
images/roadmap_logo_orange_grey.png 3.81 kB [emitted]
images/roadmap_logo_orange_white.png 3.56 kB [emitted]
images/salford_logo.png 8.36 kB [emitted]
images/select2-spinner.gif 1.85 kB [emitted]
images/select2.png 613 bytes [emitted]
images/select2x2.png 845 bytes [emitted]
images/uc3_logo_white.png 3.11 kB [emitted]
images/screencast.jpg 103 kB [emitted]
images/uc3_logo.jpg 4 kB [emitted]
images/ue_logo.png 26.9 kB [emitted]
videos/index.files/html5video/fullscreen.png 341 bytes [emitted]
videos/index.files/html5video/flashfox.swf 4.9 kB [emitted]
videos/index.files/html5video/html5ext.js 3.51 kB [emitted]
videos/index.files/html5video/screencast.jpg 103 kB [emitted]
videos/index.files/html5video/screencast.mp4 12.3 MB [emitted] [big]
videos/index.files/html5video/screencast.webm 13.7 MB [emitted] [big]
videos/index.files/html5video/screencast.m4v 13.8 MB [emitted] [big]
videos/index.files/html5video/screencast.ogv 24.7 MB [emitted] [big]
[15] ./javascripts/utils/links.js 4.71 kB {0} [built]
[18] ./javascripts/utils/paginable.js 1.09 kB {0} [built]
[27] ./javascripts/views/org_admin/questions/sharedEventHandlers.js 1.3 kB {0} [built]
[28] ./javascripts/views/org_admin/question_options/index.js 1.52 kB {0} [built]
[156] multi jquery timeago.js jquery-accessible-autocomplete-list-aria/jquery-accessible-autocomplete-list-aria jquery-ujs 64 bytes {1} [built]
[159] multi ./javascripts/application.js ./stylesheets/application.scss 40 bytes {0} [built]
[160] ./javascripts/application.js 1.77 kB {0} [built]
[236] ./javascripts/views/shared/sign_in_form.js 1.81 kB {0} [built]
[238] ./javascripts/views/super_admin/themes/new_edit.js 424 bytes {0} [built]
[239] ./javascripts/views/super_admin/users/edit.js 485 bytes {0} [built]
[240] ./javascripts/views/usage/index.js 7.67 kB {0} [built]
[289] ./javascripts/views/users/notification_preferences.js 622 bytes {0} [built]
[290] ./javascripts/views/users/admin_grant_permissions.js 4.43 kB {0} [built]
[291] ./javascripts/views/super_admin/notifications/edit.js 509 bytes {0} [built]
[292] ./stylesheets/application.scss 41 bytes {0} [built]
+ 291 hidden modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js!node_modules/sass-loader/lib/loader.js!stylesheets/application.scss:
10 assets
[1] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./stylesheets/application.scss 214 kB {0} [built]
+ 13 hidden modules
Since running npm run bundle doesn't display the terminal new line prompt (I'm talking about the $ character), I thought it is like a server, constantly serving the asset files for my rails application to use.
I refresh the website and it shows the image and layout beautifully.
I stop the webpack by pressing CTRL + C and reload the website again, it still shows the image and layout beautifully and I falsely concluded that the webpack is now serving the file in background.
But I'm wrong.
After I stopped the webpack process by pressing CTRL + C, Webpack stopped serving the files. But since it already compiled the asset files and store them in the public directory inside my project directory before, my website just use the files in there. This is the actual reason why the website still shows the images and layout beautifully.
So, to stop npm run bundle which is the same as calling webpack in my case, I can indeed simply just press CTRL + C.
For npm run bundle -- -p, I don't know what it is doing now, after running it (given that I have already run npm run bundle and stop it using CTRL + C), the website stops showing the images and layout properly.
Also, the reason that I see the PID keep changing when I call ps aux | grep webpack is because grep is the process that I'm seeing and each time I start a grep, it will be a new different process, so it will have different PID. The webpack process is already stopped when I press CTRL + C.
I am new to spark and am trying to run spark on my hadoop node CentOS7, which is on a vmware: 2GB RAM, 20GB disk, 1CPU
I am receiving this error message:
[root#xie1 spark]# bin/spark-shell
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000c0000000, 716177408, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 716177408 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /opt/spark/hs_err_pid79417.log
After some googling I checked the mem below:
[root#xie1 spark]# cat /proc/meminfo
MemTotal: 1868688 kB
MemFree: 76428 kB
MemAvailable: 80840 kB
Buffers: 68 kB
Cached: 92172 kB
SwapCached: 189260 kB
Active: 1158888 kB
Inactive: 426036 kB
Active(anon): 1108308 kB
Inactive(anon): 389960 kB
Active(file): 50580 kB
Inactive(file): 36076 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 2097148 kB
SwapFree: 282684 kB
Dirty: 76 kB
Writeback: 0 kB
AnonPages: 1303360 kB
Mapped: 42176 kB
Shmem: 5596 kB
Slab: 95580 kB
SReclaimable: 34792 kB
SUnreclaim: 60788 kB
KernelStack: 19616 kB
PageTables: 32960 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3031492 kB
Committed_AS: 6290644 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 173440 kB
VmallocChunk: 34359561216 kB
HardwareCorrupted: 0 kB
AnonHugePages: 319488 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 102272 kB
DirectMap2M: 1994752 kB
DirectMap1G: 0 kB
what's the meaning of "VmallocTotal: 34359738367 kB", it exceeds the disk size I allocate to the VM which is 20G. Is VmallocTotal some where that can be adjusted? I am guessing the spark is asking for more resource, based on my current allocation of VM, what can I do? and how to do it?
Thank you very much.
I'm trying to run an RoR app on an Amazon micro instance (the one which comes in the free tier). However, I'm being unable to successfully complete rake assets:precompile because it supposedly runs out of RAM and the system kills the process.
First, how can I be sure that this is a low memory issue?
Second, irrespective of the answer to the first question, are there some parameters that I can pass to the Ruby interpreter to make it consume less RAM -- even if at the cost of overall app performance? Any GC tuning possible? Anything at all?
Note: Similar to Making ruby on rails take up less memory
PS: I've added a a file-based swap area to the system as well. Here's the output of cat /proc/meminfo if that helps:
MemTotal: 604072 kB
MemFree: 343624 kB
Buffers: 4476 kB
Cached: 31568 kB
SwapCached: 33052 kB
Active: 17540 kB
Inactive: 199588 kB
Active(anon): 11408 kB
Inactive(anon): 172644 kB
Active(file): 6132 kB
Inactive(file): 26944 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 292840 kB
SwapFree: 165652 kB
Dirty: 80 kB
Writeback: 0 kB
AnonPages: 149640 kB
Mapped: 6620 kB
Shmem: 2964 kB
Slab: 23744 kB
SReclaimable: 14044 kB
SUnreclaim: 9700 kB
KernelStack: 2056 kB
PageTables: 6776 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 594876 kB
Committed_AS: 883644 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 5200 kB
VmallocChunk: 34359732767 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 637952 kB
DirectMap2M: 0 kB
Put config.assets.initialize_on_precompile = false in application.rb to avoid initializing the app and the database connection when you precompile assets. That may help.
Another option is to precompile locally and then deploy the compiled assets. More info here http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
Second question first - I have run Rails apps on Micro instances, and do so now. So long as your concurrency is very low (one or two active users, tops. And not super-active either) you will be ok. Also note that Amazon will arbitrarily throttle down your effective CPU whenever it wants if you try to slam the CPU too hard (that's just how they do Micro instances). No GC tweaks or anything like that are necessary, just default settings are fine. I was using Passenger, an older version, and made sure it was spinning up only one process spawner. Stock config. Especially if big chunks of your app are images or static files, your main web server will be serving most of that content, and not Rails.
For your second question - I just checked out a large(ish) rails app, fat_free_crm, on a freshly spun-up micro instance. I was just looking for something big.
I timed a run of assets:precompile and it did complete - after a very long time. I timed it and it seemed to finish in 2 minutes 31 seconds.
I think you might still need more swapspace. I would try a gig to start with. If you still can't precompile your assets after that, you've got some other problem.
dd if=/dev/zero of=/swapfile bs=1k count=1M
mkswap /swapfile
swapon -f /swapfile
I have compared /proc/meminfo for a galaxys2 (arm exynos4) device running Android gingerbread and ice cream sandwich (cyanogen CM9). I noticed that the kernel splits the memory differently between low memory and high memory:
For ICS/CM9 (3.0 kernel):
cat /proc/meminfo:
MemTotal: 843624 kB
MemFree: 68720 kB
Buffers: 1532 kB
Cached: 115720 kB
SwapCached: 0 kB
Active: 487780 kB
Inactive: 64524 kB
Active(anon): 436316 kB
Inactive(anon): 1764 kB
Active(file): 51464 kB
Inactive(file): 62760 kB
Unevictable: 748 kB
Mlocked: 0 kB
**HighTotal: 278528 kB**
HighFree: 23780 kB
**LowTotal: 565096 kB**
LowFree: 44940 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 435848 kB
Mapped: 45364 kB
Shmem: 2276 kB
Slab: 37996 kB
SReclaimable: 10028 kB
SUnreclaim: 27968 kB
KernelStack: 10064 kB
PageTables: 16688 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 421812 kB
Committed_AS: 8549052 kB
VmallocTotal: 188416 kB
VmallocUsed: 104480 kB
VmallocChunk: 26500 kB
For GB (2.6 kernel):
cat /proc/meminfo:
MemTotal: 856360 kB
MemFree: 22264 kB
Buffers: 57000 kB
Cached: 337320 kB
SwapCached: 0 kB
Active: 339064 kB
Inactive: 379148 kB
Active(anon): 212928 kB
Inactive(anon): 112964 kB
Active(file): 126136 kB
Inactive(file): 266184 kB
Unevictable: 396 kB
Mlocked: 0 kB
**HighTotal: 462848 kB**
HighFree: 1392 kB
**LowTotal: 393512 kB**
LowFree: 20872 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 324312 kB
Mapped: 97092 kB
Shmem: 1580 kB
Slab: 29160 kB
SReclaimable: 13924 kB
SUnreclaim: 15236 kB
KernelStack: 8352 kB
PageTables: 23828 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 428180 kB
Committed_AS: 4001404 kB
VmallocTotal: 196608 kB
VmallocUsed: 104804 kB
VmallocChunk: 57092 kB
I have noticed that on the 3.0 kernel memory pressure is evident and the out of memory killer is invoked frequently.
I have two questions regarding this:
Is is possible that in the 3.0 layout (less highmem more lowmem) applications have less available memory? Could that explain the high memory pressure?
Is it possible to change the layout in the 3.0 kernel in order to make it more similar to the 2.6 layout (i.e. more highmem less lowmem)?
As far as I recall, the split between high and low memory is a compilation parameter of the Kernel, so it should be possible to set it differently (at compile time). I do not know why so much is given to the high memory region on your examples. On x86 with 1 GB physical RAM it is about 896 MB for low memory and 128 MB is high memory.
It would seem that Android needs more high memory than a typical 32 bit x86 desktop, I do not know which feature(s) of the Android echo-system would bring such requirements, so hopefully somebody else can tell you that.
You could try to investigate the memory zones to try to see what is the difference between Android ICS and GB. Simply do a cat /proc/zoneinfo. You can find some background information on these zones in this article, although take care that it was described for x86 arch.