[Javalist] play / c3p0pooledconn ...
Hollósi Balázs
hollosi.balazs at 1101.hu
2012. Jan. 24., K, 23:15:06 CET
kiprobaltam -XX:-UseCompressedOops kapcsoloval, remote debug, szepen
hasal igy is
Internal Error (synchronizer.cpp:1401), pid=23812, tid=139974289278720
# guarantee(mid->header()->is_neutral()) failed: invariant
#
# JRE version: 6.0_30-b12
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.5-b03 mixed mode linux-amd64 )
ez most sun jdk, de probaltam jrockit-el is, openjdk meg nem volt..
eddig csak a bajom volt vele, de egy probat meger..
2012/1/24 Gábor Garami <gabor.garami at hron.me>:
> Akartam is kerdezni, hogy ez amugy milyen jdk? Mert minden sunos jdk-val
> tamogatott csak.
>
> Ezt a levelet telefonról adták fel ezért esetenként ékezethibákat
> tartalmazhat.
>
> Garami Gábor
> E-mail: gabor.garami at hron.me
> Web: http://hron.me
> Skype: hron84
> MSN: hrgy at vipmail.hu
>
> 2012.01.24. 22:35, "Zsombor" <gzsombor at gmail.com> ezt írta:
>
>> Én a vm-et cserélném le (openjdk/icedtea/stb), miután végig kerestem, hogy
>> ilyen gyanús libjvm-ből származó sigsegv-eket látott e bárki is.
>> Ezenkivül a compressed oops-ot is ki lehetne kapcsolni, úgy rémlik, hogy
>> az valami új kisérletibb ficsör.
>>
>>
>> On Tue, Jan 24, 2012 at 22:23, Hollósi Balázs <hollosi.balazs at 1101.hu>
>> wrote:
>>>
>>> újabb próba, db -t kizárom, semmi pg speci nincs még, átállítottam
>>> mysql-re, had szóljon. így meg sorra jönnek a vm crash-ek.. persze
>>> mindig más, egzotikus..
>>>
>>> ----
>>> # SIGSEGV (0xb) at pc=0x00007f3ff1cea1ae, pid=10726, tid=139912539502336
>>> #
>>> # JRE version: 6.0_30-b12
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.5-b03 mixed mode
>>> linux-amd64 compressed oops)
>>> # Problematic frame:
>>> # V [libjvm.so+0x3e91ae]
>>> DefNewGeneration::copy_to_survivor_space(oopDesc*)+0x3e
>>> ----
>>> # Internal Error (synchronizer.cpp:1399), pid=12266, tid=140560676685568
>>> # guarantee(obj->mark() == markOopDesc::encode(mid)) failed: invariant
>>> ----
>>> az utóbbinál szimplán megállt 324 request után a loadui kiszolgálása.
>>> kezd az agyamra menni..
>>>
>>> viszont c3p0 kihagyása ha jól láttam csak úgy lehetséges ha j2ee
>>> konténerben futtatom, és jndi-n keresztül kapja a kapcsolatot.. jöjjön
>>> hát a glassfish.. grr..
>>>
>>> b
>>>
>>> 2012/1/24 Gábor Garami <gabor.garami at hron.me>:
>>> > En se gondolom, h az oom-killer dolgozna, az levagna a komplett
>>> > appszervert.
>>> > Inkabb vmi jdbc nyug lehet ez, v. tenyleg a c3p0 problemaja. Esetleg db
>>> > szerver gond... :-)
>>> >
>>> > Ezt a levelet telefonról adták fel ezért esetenként ékezethibákat
>>> > tartalmazhat.
>>> >
>>> > Garami Gábor
>>> > E-mail: gabor.garami at hron.me
>>> > Web: http://hron.me
>>> > Skype: hron84
>>> > MSN: hrgy at vipmail.hu
>>> >
>>> > 2012.01.24. 16:24, "Laszlo Hornyak" <laszlo.hornyak at gmail.com> ezt
>>> > írta:
>>> >
>>> >> Hali!
>>> >>
>>> >> Ha a kernel OOM killerre gondolsz, az az egesz processzedet csapja le
>>> >> szerintem, azaz a JVM-et. Threadeket talan nem lenne ertelme, a
>>> >> szalaknak nincs sajat memoria szegmensuk.
>>> >>
>>> >> 2012/1/24 András Csányi <sayusi.ando at gmail.com>:
>>> >> > 2012/1/24 Balázs Hollósi <hollosibalazs at gmail.com>:
>>> >> >> sziasztok
>>> >> >>
>>> >> >> igazából olyan vizeken evezek, ahol nem sok helyismeretem van,
>>> >> >> ezért
>>> >> >> bármi nemű segítséget köszönök.
>>> >> >>
>>> >> >> tehát. van egy play framework webes alkalmazásom, postgres
>>> >> >> adatbázissal. eddig tök jól ment minden, viszont a hosting cég ahol
>>> >> >> van (vps) konfigolt egyet, és most érdekességek történnek. a cég
>>> >> >> alapvetően konstruktív, már átraktak egy másik node-ra, ahol a
>>> >> >> config
>>> >> >> ua, de a vas más, ergo a memória hibát meg a többi hw parát úgy
>>> >> >> gondolom kizárhatom. eddig a vps 4 cpu-t látott (/proc/cpuinfo)
>>> >> >> most
>>> >> >> egy magot, amelyik azt mondja magáról hogy 4 magos, gondolom a
>>> >> >> virtualizáción állítottak, azért lett más, lényegében a sebesség
>>> >> >> maradt, ezzel sincs gondom.
>>> >> >>
>>> >> >> a jelenség hogy egyszercsak felugrik a java process load-ja
>>> >> >> 100%-ra,
>>> >> >> még egy darabig működik az alkalmazás, de rosszabb esetben
>>> >> >> segfault-ol
>>> >> >> a vm, jobbik esetben izzasztja a vasat, és 4-5ös load mellett azért
>>> >> >> néha kiszolgál egy-egy requestet. ja igen, demo alkalmazás,
>>> >> >> bármilyen
>>> >> >> "eszköz" engedélyezett :)
>>> >> >>
>>> >> >> debug módban elindítottam a vm-et, és remote rácsatlakoztam.
>>> >> >> eclipse
>>> >> >> alatt szép sorban suspend a szálakra, így meglett a bőnös
>>> >> >> (legnagyobb
>>> >> >> meglepetésre nem a play szál).
>>> >> >>
>>> >> >> a bűnös thread stack:
>>> >> >>
>>> >> >>
>>> >> >> Daemon Thread
>>> >> >> [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0]
>>> >> >> (Suspended)
>>> >> >> Finalizer.add() line: 42
>>> >> >> Finalizer.<init>(Object) line: 67
>>> >> >> Finalizer.register(Object) line: 72
>>> >> >> Jdbc4Statement(Object).<init>() line: 20
>>> >> >>
>>> >> >>
>>> >> >> Jdbc4Statement(AbstractJdbc2Statement).<init>(AbstractJdbc2Connection,
>>> >> >> int, int) line: 135
>>> >> >>
>>> >> >>
>>> >> >> Jdbc4Statement(AbstractJdbc3Statement).<init>(AbstractJdbc3Connection,
>>> >> >> int, int, int) line: 36
>>> >> >>
>>> >> >>
>>> >> >> Jdbc4Statement(AbstractJdbc3gStatement).<init>(AbstractJdbc3Connection,
>>> >> >> int, int, int) line: 23
>>> >> >>
>>> >> >> Jdbc4Statement(AbstractJdbc4Statement).<init>(Jdbc4Connection,
>>> >> >> int,
>>> >> >> int, int) line: 26
>>> >> >> Jdbc4Statement.<init>(Jdbc4Connection, int, int, int) line:
>>> >> >> 25
>>> >> >> Jdbc4Connection.createStatement(int, int, int) line: 30
>>> >> >>
>>> >> >> Jdbc4Connection(AbstractJdbc3Connection).createStatement(int,
>>> >> >> int) line: 231
>>> >> >>
>>> >> >>
>>> >> >> Jdbc4DatabaseMetaData(AbstractJdbc2DatabaseMetaData).createMetaDataStatement()
>>> >> >> line: 4266
>>> >> >>
>>> >> >>
>>> >> >> Jdbc4DatabaseMetaData(AbstractJdbc2DatabaseMetaData).getTables(String,
>>> >> >> String, String, String[]) line: 2069
>>> >> >>
>>> >> >> DefaultConnectionTester.activeCheckConnectionNoQuery(Connection,
>>> >> >> Throwable[]) line: 185
>>> >> >> DefaultConnectionTester.activeCheckConnection(Connection,
>>> >> >> String,
>>> >> >> Throwable[]) line: 62
>>> >> >>
>>> >> >>
>>> >> >> DefaultConnectionTester(AbstractConnectionTester).activeCheckConnection(Connection)
>>> >> >> line: 67
>>> >> >>
>>> >> >>
>>> >> >> C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.testPooledConnection(Object)
>>> >> >> line: 368
>>> >> >>
>>> >> >>
>>> >> >> C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.refurbishIdleResource(Object)
>>> >> >> line: 310
>>> >> >> BasicResourcePool$AsyncTestIdleResourceTask.run() line: 1999
>>> >> >> ThreadPoolAsynchronousRunner$PoolThread.run() line: 547
>>> >> >>
>>> >> >> ez ha jól tudom db pool cucc. viszont otthon, meg eddig kint is ua
>>> >> >> verzió (play embeddelt) fut, otthon még most is, kint eddig stabil
>>> >> >> volt.
>>> >> >> első körben a kérdésem, találkozott-e már valaki hasonló parával.
>>> >> >> ismert-e hogy 1 (virtuális) magos környezetben gondok lennének
>>> >> >> vele? egyéb javaslat?
>>> >> >>
>>> >> >> ezer köszi előre is,
>>> >> >> B
>>> >> >
>>> >> > Mindig ez a hiba? Ezt azért kérdezem, mert ha ez a virtualizált
>>> >> > környezet linux, akkor az is lehet, hogy az a terheltség, amit kap
>>> >> > elviszi oda az oprendszert, hogy magától elkezdi kinyírni a szálakat
>>> >> > (nem jut most eszembe, hogy mi a neve ennek a jószágnak a
>>> >> > kernelben).
>>> >> >
>>> >> > --
>>> >> > - -
>>> >> > -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu --
>>> >> > http://facebook.com/andras.csanyi
>>> >> > -- ""Trust in God and keep your gunpowder dry!" - Cromwell
>>> >> > _______________________________________________
>>> >> > Javalist mailing list
>>> >> > Javalist at lists.javaforum.hu
>>> >> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> EOF
>>> >> _______________________________________________
>>> >> Javalist mailing list
>>> >> Javalist at lists.javaforum.hu
>>> >> http://lists.javaforum.hu/mailman/listinfo/javalist
>>> >
>>> >
>>> > _______________________________________________
>>> > Javalist mailing list
>>> > Javalist at lists.javaforum.hu
>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>> >
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
További információk a(z) Javalist levelezőlistáról