[Javalist] play / c3p0pooledconn ...

Laszlo Hornyak laszlo.hornyak at gmail.com
2012. Jan. 24., K, 13:44:51 CET


Hali!

A virtualizaciotol nem szabad hogy fuggjon, de az azert elkepzelheto,
hogy a masfele terheles elohozott egy eddig rejtve maradt concurrency
hibat.
Ha megis a virtualizacio miatt van, az azt jelenti, hogy szar a
virtualizacio :-(

Izgi ez a c3p0-s dolog. Csak otlet, de esetleg kapcsold ki a
connection checket, vagy esetleg ne az osszes tablat szedje ossze a
DB-bol, csak egy "select 1"-et nyomjon...
Jobb ez a c3p0 mint a commons dbcp?


2012/1/24 Hollósi Balázs <hollosi.balazs at 1101.hu>:
> hali
>
> ssd hosting, és a munin user load-ot mutat, nem iowait-et (htop is).
> próbáltam jrockit-el, érdekes módon ott nice load volt nagy, de a
> jelenség ua. gondolom ott a daemon processnek szépen beállítottak nice
> levelt.
> memória bőven van, nem swappel. a diszkre nem gyanakodnék, ioping
> statisztikája 1.3 millisec átlagos késleltetést, és 227MB/s átlagos
> sebességet mutat.
>
> b
>
> 2012/1/24 Istvan Verhas <istvan at verhas.com>:
>> Ha a gépnek nagy a load-ja (függetlenül attól, hogy fizikai vagy virtuális) akkor első lépésben azt kell kideríteni, hogy miért és nem azt, hogy mi okozza. A load csak annyit tesz, hogy időegység alatt mennyi az elvégzendő feladat vagy éppen mennyi vár a sorára. A miértre alapvetően két válasz lehetséges: processzor, I/O. Ha processzor nem pörög 100%-on akkor az I/O-ban a következő problémák lehetnek: kevés a memória és swap-el, lassú a diszk hozzáférés és írásra/olvasásra vár vagy a network kevés és arra vár. Mindezek kiderítéséhez egy kellemes eszköz a vmstat.
>> Virtuális környezetben személyes tapasztalatom szerint a diszk hozzáférés szokott belassulni ha nincs jól konfigurálva, de ez csak egy nagyon kis mintavételezés.
>>
>> Verhás István
>> JIRA szakértő
>> Verhás & Verhás Szoftver Manufaktúra Kft.
>> istvan at verhas.com
>> t: +36(30)3997117
>> skype: verhasi
>>
>> On Jan 24, 2012, at 11:23 AM, Balázs Hollósi wrote:
>>
>>> 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
>>> _______________________________________________
>>> 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



-- 

EOF


További információk a(z) Javalist levelezőlistáról