i am working on a ruby project. and i used tunemygc gem to get some optimal settings for my app.
RUBY_GC_HEAP_INIT_SLOTS 220886
RUBY_GC_HEAP_FREE_SLOTS 3378483
RUBY_GC_HEAP_GROWTH_FACTOR 1.03
RUBY_GC_HEAP_GROWTH_MAX_SLOTS 478
RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR 2.0
RUBY_GC_MALLOC_LIMIT 16777216
RUBY_GC_MALLOC_LIMIT_MAX 30198989
RUBY_GC_MALLOC_LIMIT_GROWTH_FACTOR 1.32
RUBY_GC_OLDMALLOC_LIMIT 16777216
RUBY_GC_OLDMALLOC_LIMIT_MAX 30198989
RUBY_GC_OLDMALLOC_LIMIT_GROWTH_FACTOR 1.2
but i don't know how to config my garbage collection with these settings.
Set those as environment variables on your server that are available to the ruby process when it starts. As in:
export RUBY_GC_HEAP_INIT_SLOTS=220886
...
Then start your ruby app
If your app is on heroku, you can also use the free heroku add on, and apply all the recommended settings with just one button.
Related
I am trying to migrate a Play 2.5 version to 2.6.2. I keep getting the URI-length exceeds error. Anyone knows how to override this?
I tried below Akka setting but still no luck.
play.server.akka{
http.server.parsing.max-uri-length = infinite
http.client.parsing.max-uri-length = infinite
http.host-connection-pool.client.parsing.max-uri-length = infinite
http.max-uri-length = infinite
max-uri-length = infinite
}
Simply add
akka.http {
parsing {
max-uri-length = 16k
}
}
to your application.conf. The prefix play.server is only used for a small subset of convenience features for Akka-HTTP integration into the Playframework, e.g. play.server.akka.requestTimeout. Those are documented in the Configuring the Akka HTTP server backend documentation.
I was getting error due to header length exceeding default 8 KB(8192). Added the following to build.sbt and it worked for me :D
javaOptions += "-Dakka.http.parsing.max-header-value-length=16k"
You can try similar for uri length if other options don't work
This took me way to long to figure out. It is somehow NOT to be found in the documentation.
Here is a snippet (confirmed working with play 2.8) to put in your application.conf which is also configurable via an environment variable and works for BOTH dev and prod mode:
# Dev Mode
play.akka.dev-mode.akka.http.parsing.max-uri-length = 16384
play.akka.dev-mode.akka.http.parsing.max-uri-length = ${?PLAY_MAX_URI_LENGTH}
# Prod Mode
akka.http.parsing.max-uri-length = 16384
akka.http.parsing.max-uri-length = ${?PLAY_MAX_URI_LENGTH}
You can then edit the config or with an already deployed application just set PLAY_MAX_URI_LENGTH and it is dynamically configurable without the need to modify commandline arguments.
env PLAY_MAX_URI_LENGTH=16384 sbt run
If anyone getting this type of error in chrome browser when trying to access a site or login. [HTTP header value exceeds the configured limit of 8192 characters]
, Go to chrome
settings -> Security and Privacy -> Site Settings , View Permission and data stored across sites
Search for the specific website and on that site do Clear all data.
We have been trying to make use of the RabbitMQ Service Bus (v3.3.4) but the central bus keeps crashing. At the moment we are not using any clustering and its hosted on Windows Server 2008 R2. We'd like to isolate the root cause but the below error is the only one we can find. Can anyone shed some light on what; if anything; we can do to find the root cause of this?
Note: There are roughly 20 consumers with roughly the same number of Topic subscriptions. Also, all the clients are .NET 4.5 using the 3.3.4 Rabbit client libraries.
Version=1
EventType=APPCRASH
EventTime=130658038736577295
ReportType=2
Consent=1
ReportIdentifier=7f93ccd8-9cbe-11e4-ae00-000c29c08139
IntegratorReportIdentifier=7f93ccd7-9cbe-11e4-ae00-000c29c08139
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=erl.exe
Sig[1].Name=Application Version
Sig[1].Value=0.0.0.0
Sig[2].Name=Application Timestamp
Sig[2].Value=5343035d
Sig[3].Name=Fault Module Name
Sig[3].Value=MSVCR100.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=10.0.30319.1
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=4ba220dc
Sig[6].Name=Exception Code
Sig[6].Value=40000015
Sig[7].Name=Exception Offset
Sig[7].Value=00000000000760d9
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7600.2.0.0.272.7
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=8d79
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=8d79a00078e92d9c3d5d79d4324254fe
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=9af5
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=9af5b20633c279dbf44b04a614c6a1f6
UI[2]=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=erl.exe stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\system32\kernel32.dll
LoadedModule[3]=C:\Windows\system32\KERNELBASE.dll
LoadedModule[4]=C:\Windows\system32\MSVCR100.dll
LoadedModule[5]=C:\Program Files\erl6.0\erts-6.0\bin\erlexec.dll
LoadedModule[6]=C:\Windows\system32\USER32.dll
LoadedModule[7]=C:\Windows\system32\GDI32.dll
LoadedModule[8]=C:\Windows\system32\LPK.dll
LoadedModule[9]=C:\Windows\system32\USP10.dll
LoadedModule[10]=C:\Windows\system32\msvcrt.dll
LoadedModule[11]=C:\Windows\system32\IMM32.DLL
LoadedModule[12]=C:\Windows\system32\MSCTF.dll
LoadedModule[13]=C:\Windows\system32\apphelp.dll
LoadedModule[14]=C:\Program Files\erl6.0\erts-6.0\bin\beam.dll
LoadedModule[15]=C:\Windows\system32\ADVAPI32.dll
LoadedModule[16]=C:\Windows\SYSTEM32\sechost.dll
LoadedModule[17]=C:\Windows\system32\RPCRT4.dll
LoadedModule[18]=C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_fa62ad231704eab7\COMCTL32.dll
LoadedModule[19]=C:\Windows\system32\SHLWAPI.dll
LoadedModule[20]=C:\Windows\system32\COMDLG32.dll
LoadedModule[21]=C:\Windows\system32\SHELL32.dll
LoadedModule[22]=C:\Windows\system32\WS2_32.dll
LoadedModule[23]=C:\Windows\system32\NSI.dll
LoadedModule[24]=C:\Windows\system32\IPHLPAPI.DLL
LoadedModule[25]=C:\Windows\system32\WINNSI.DLL
LoadedModule[26]=C:\Windows\system32\mswsock.dll
LoadedModule[27]=C:\Windows\System32\wshtcpip.dll
LoadedModule[28]=C:\Windows\system32\NLAapi.dll
LoadedModule[29]=C:\Windows\system32\DNSAPI.dll
LoadedModule[30]=C:\Windows\System32\winrnr.dll
LoadedModule[31]=C:\Windows\system32\napinsp.dll
LoadedModule[32]=C:\Windows\System32\wship6.dll
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=erl.exe
AppPath=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
I'm using equinox weaving to do aspect across bundles in Virgo tomcat, I followed the weaving sample. It worked fine in eclipse target platform. But when I deployed into virgo, it didn't work.
I modified config.ini like below
……
osgi.framework.extensions=org.eclipse.equinox.weaving.hook_1.0.200.I20130319-1000
osgi.bundles=org.eclipse.equinox.weaving.aspectj#2\:start,org.aspectj.weaver#2\:start,org.aspectj.runtime#2\:start
aj.weaving.verbose=true
org.aspectj.weaver.showWeaveInfo=true
org.aspectj.osgi.verbose=true
……
No exception occrred when starting Virgo, and bundles' state were correct
id State Bundle
0 ACTIVE org.eclipse.osgi_3.8.1.v20120830-144521
Fragments=1, 34
1 RESOLVED org.eclipse.equinox.weaving.hook_1.0.200.I20130319-1000
Master=0
2 ACTIVE org.eclipse.equinox.weaving.aspectj_1.0.300.I20130319-1000
3 ACTIVE org.aspectj.weaver_1.7.3.20130613144500-a
4 ACTIVE org.aspectj.runtime_1.7.3.20130613144500-a
I found some difference in consoles. When starting in eclipse target platform, next tow statements displayed in consoles
[org.eclipse.equinox.weaving.hook] info adding AspectJ hooks ...
[org.eclipse.equinox.weaving.aspectj] info Starting AspectJ weaving service ...
But when starting in Virgo, just the second one displayed. I considered maybe the hook didn't start correctly, but i'm not sure. Anyone can help me?
So I'm getting page load times in the range of 30-45 seconds.
Some history:
This was not always the case for this project. This project is in production so I haven't really touched the code in a while. I noticed it started happening the last time I was updating the code. I don't recall anything specific that I changed that should have anything to do with the problem. I have other projects that are running with the same Grails versions with no problem.
I think it started happening in 2.2.3. I am now running 2.2.4.
I am using x64 JDK 1.7.0_25, Windows 7 x64.
I'm not sure what else to put here that would be relevant. Any assistance is appreciated!
Edit: running with -noreloading has no effect.
Edit2: I've tried deleting my .grails folder entirely, running clean, and deleting my target folder and stacktrace log.
Edit3: It does seem that the amount of time it takes is dependent on the amount of data displayed/read. Small pages take 3-4 seconds. Medium pages 10-12 seconds...
Edit4: I'm running it via IntelliJ IDEA 12.1.4 x64 (idea64.exe). I've also tried it outside of IntelliJ with the same results.
Edit5: The database is Oracle enterprise that supports the entire company. It is managed by full time adminstrators. This isn't a MySQL server on my local machine.
Edit6: The application also functions normally when deployed in TEST (test war), but still is slow when ran with test run-app.
Starting to get somewhere:
I downloaded JDK 1.7.21 and ran the app with that and it started working no problem! I then ran clean which triggered a recompile and it stopped working... grr
Now with 1.7.21 still active, I tried -noreloading and it works!
Annnd... now it works even if I don't use -noreloading..........
I've gone back to 1.7.25.. ran clean, and it works. Sooooooo yeah... explain that.
And now it doesn't anymore.
This is under Linux but will maybe useful:
If you are running the code within an IDE:
ps auwx|grep java
-Dgrails.console.class=grails.build.logging.GrailsEclipseConsole -Dosgi.requiredJavaVersion=1.6 -Xms40m -Xmx768m -XX:MaxPermSize=256m -
As you can see the memory settings Xms and Xmx are quite low...
In your IDE there should be an INI file:
more STS.ini
1 -vm
2 /usr/lib/jvm/java-6-openjdk-amd64/bin/java
3 -startup
4 plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
5 --launcher.library
6 plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20120913-144807
7 -product
8 org.springsource.sts.ide
9 --launcher.defaultAction
10 openFile
11 -vmargs
12 -Dgrails.console.enable.interactive=false
13 -Dgrails.console.enable.terminal=false
14 -Djline.terminal=jline.UnsupportedTerminal
15 -Dgrails.console.class=grails.build.logging.GrailsEclipseConsole
16 -Dosgi.requiredJavaVersion=1.6
17 -Xms40m
18 -Xmx768m
19 -XX:MaxPermSize=256m
You can up these value and try restarting your IDE...
I would also suggest you run something like nmon before/during and monitor whilst the code is running and monitor disk/cpu/network throughputs.
You may find you are hammering your dev box which is causing the issue.
If the production is fine I really don't see what the problem is..
E2A Ahhh forgot it was under windows so no nmon for windblows but hey not that I tried it - http://sourceforge.net/projects/jnmonanalyser/
E2A again:
1. Enable DataSource.groovy debugging:
dataSource {
pooled = true
driverClassName ="com.mysql.jdbc.Driver"
username = "aaa"
password = "aaaa"
//SQL Logging - refer to Config.groovy at hibernate.sql now
logSql=true
...
config.groovy - this will stop your app from running if you have issues with lets say records you are trying to add in your BootStrap
// Return error when it fails
//grails.gorm.failOnError=true
Enable log4j and use this or part of it:
// log4j configuration
log4j {
appender.stdout = "org.apache.log4j.ConsoleAppender"
appender.'stdout.layout'="org.apache.log4j.PatternLayout"
appender.'stdout.layout.ConversionPattern'='[%r] %c{2} %m%n'
appender.stacktraceLog = "org.apache.log4j.FileAppender"
appender.'stacktraceLog.layout'="org.apache.log4j.PatternLayout"
appender.'stacktraceLog.layout.ConversionPattern'='[%r] %c{2} %m%n'
appender.'stacktraceLog.File'="stacktrace.log"
appender.'stacktraceLog.MaxFileSize'="1MB"
rootLogger="error,stdout"
logger {
grails="error"
StackTrace="error,stacktraceLog"
org {
codehaus.groovy.grails.web.servlet="error" // controllers
codehaus.groovy.grails.web.pages="error" // GSP
codehaus.groovy.grails.web.sitemesh="error" // layouts
codehaus.groovy.grails."web.mapping.filter"="error" // URL mapping
codehaus.groovy.grails."web.mapping"="error" // URL mapping
codehaus.groovy.grails.commons="info" // core / classloading
codehaus.groovy.grails.plugins="error" // plugins
codehaus.groovy.grails.orm.hibernate="error" // hibernate integration
// Hibernate should be on - if you want to catch sql logs
springframework="off"
hibernate="on"
//hibernate.SQL = 'debug'
//hibernate.type = 'trace'
//hibernate.SQL = 'info,hibernate'
//hibernate.type = 'info,hibernate'
//hibernate = 'info,hibernate'
//apache.commons.digester.Digester = 'debug,javaclasses'
}
}
additivity.StackTrace=false
}
try and capture what it is doing, it is also worth running developer tools on your browser whether its firefox of chrome and trying to figure out on what elements it is taking that time - but between the logs and the browser developer tools should lie your answer.
Usually you can fix this by doing
grails clean
on the grails command line (I open it via CRTL+ALT+G in IntelliJ IDEA).
This erases all compiled files and will recompile your project from scratch (afaik), which usually erases errors like that. This is not a real fix for the underlying problem, but it solves the problem. Grails is highly experimental and unstable if you ask me, i have a lot of weird error that usually disappear when doing a clean. Btw i'm using 2.1.5 on Windows 7 x64, too.
Delete stacktrace file in the target folder of your project. It can
get huge. (At present mine is 48 GB).
Check if there is enough space in your C directory.
If you are hot swapping code, then page loads can get slow. So in such cases, restart the dev server (grails app).
Sometimes, requests to the server can hang, where focusing (left or right clicking on the cmd) on the command prompt seems to skip the pause. (weird)
Increasing the JVM permgen, heap spaces depending on your memory might help as well.
Try running the server using command prompt rather within an IDE.
Better use methods for actions than closures.
For a system with 3GB RAM, my environment variable setting is:
JAVA_OPTS
-Xms512m -Xmx1g
The STS.ini settings:
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20110502
-product
com.springsource.sts.ide
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
384M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xmn128m
-Xms1024m
-Xmx1024m
-Xss2m
-XX:PermSize=256m
-XX:MaxPermSize=512m
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=50
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:+UserParallelGC
8) Maybe the problem is with the JDK and grails versions combination. There seems to be an error with OpenJDK 1.7u25 and spring loaded. Okay, you are not using OpenJDK, but try with other version anyway. Try with JDK1.7u03.
9) Try JVM with -server flag, and see if it improves runtime performance.
grails run-app -server
So the reason why this was happening:
JDK 1.7.25
I am trying to wrap my brain around Rack::Cache, Rails 3.2, Memcache, and Heroku. I think I've got it all working together, as outlined here: http://myownpirateradio.com/2012/01/01/getting-heroku-cedar-and-rails-3-1-asset-pipeline-to-play-nicely-together/
All that said, I am unsure if Memcached is actually doing what it should. Is there any way to get stats on Memcached or to see if a request was cached by Memcached? I put the current time on a page, and can see that it is getting cached (headers look good too), but how do I know it is all working with Memcached, as opposed to the file store?
Thanks.
You can get stats on memcached by doing:
$ heroku run console
Running console attached to terminal... up, run.1
Loading production environment (Rails 3.1.3)
irb(main):001:0> Rails.cache.stats
Dalli/SASL authenticating as app590983%40heroku.com
Dalli/SASL: Authenticated
=> {"mc5.ec2.northscale.net:11211"=>{"evictions"=>"0", "curr_items"=>"627",
"total_items"=>"1257", "bytes"=>"2294318", "reclaimed"=>"0",
"engine_maxbytes"=>"5242880", "bucket_conns"=>"2", "pid"=>"319",
"uptime"=>"6710022", "time"=>"1330731177", "version"=>"1.4.4_207_g19c6b9e",
"libevent"=>"1.4.11-stable", "pointer_size"=>"64",
"rusage_user"=>"34354.590000", "rusage_system"=>"31381.520000",
"daemon_connections"=>"10", "curr_connections"=>"1211",
"total_connections"=>"14127919", "connection_structures"=>"1764",
"cmd_get"=>"9476", "cmd_set"=>"1257", "cmd_flush"=>"0", "auth_cmds"=>"24",
"auth_errors"=>"0", "get_hits"=>"8093", "get_misses"=>"1383",
"delete_misses"=>"0", "delete_hits"=>"0", "incr_misses"=>"0",
"incr_hits"=>"0", "decr_misses"=>"0", "decr_hits"=>"0", "cas_misses"=>"0",
"cas_hits"=>"0", "cas_badval"=>"0", "bytes_read"=>"21983909",
"bytes_written"=>"85267718", "limit_maxbytes"=>"67108864",
"rejected_conns"=>"0", "threads"=>"4", "conn_yields"=>"0"}}
PS: I think you might need to be using the Dalli gem for this to work, but that is the recommended client anyway.
You can also run Rails.cache.class to see which backend is Rails using.