[Javalist] play / c3p0pooledconn ...

2012. Jan. 24., K, 22:38:07 CET

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
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120124/e1749ff0/attachment.html>