[Megoldva-upgr.: és mégsem! :-(] ÁNYK - GC overhead limit exceeded

Iroda

Hello,

Windows7, új Java (8-as), új ÁNYK és mégis limit exceeded üzeneteket dobál. Mai modern gép sok memóriával. Mit lehet itt tenni, ezt nem hiszem el, hogy ennek még mindig így kell működnie. A nyomtatványkitöltő program a rossz vagy a környezete nem megfelelő? Ki látott ilyesmit és, hogyan tudta orvosolni?

thx

p.s..:
Köszönöm a sok hozzászólást.
Megoldás: Sajnos csak a downgrade Java 8-ról 7-esre hozta meg a megnyugvást. :-(

p.s.2:
Na ilyen állat márpedig nincs, újratelepítés, 7.71-el két bevallás után ismét dobja a hibát és használhatatlan. Ez katasztrófa! :-( Mármint az a katasztrófa, hogy nem lehet értelmesen választani, hanem mások dilettáns volta miatt szenvedni kell.

  • 7659 megtekintés

( NevemTeve | 2014. 08. 28., cs – 15:52 )

(Nem tudom, de kis szerencsével én is rá fogok szaladni a következő havi bevallásnál... sajnos túl sok a gyenge láncszem a mesében: Windows, Java, magyar programozók)

Nem én írtam, de adok neked/nektek egy magyarázatot:
- annyi féle Java verió van, mint égen a csillag, és ugyan vannak helyek, ahol mindig az Oracle-féle legutolsó verzió van fenn, más helyen meg hasraütésszerűen, a harmadikon pedig kötelezően valami hulladék régi, hogy esélyes, hogy ezek mindegyikén nem tesztelték az AbevJava csodálatos fejlesztői. És ugyan lehet, hogy van valahol egy "X.Y.Z verzió esetén garantált (nem) a hibátlan működése" - vagy legalább egy "mi A.B.C verzióval teszteltük, javallot ezen futtatni", de egyrészt én nem láttam másrészt tapasztalatom szerint az ilyen felhívásokat felülírják egyéb helyi "szabályok"

- a Win-re pont ugyanez érvényes, csak ott elvben a kismillió javítócsomag is lehet problémás, meg a 3.1-es winnel való esetleges kompatibilitási igény (nyilván ez túlzás, de nyugodj meg ha lehetne, olyan ember is volna, aki még azt használna; én is hallottam már *felhasználótól*, hogy a Win98 volt az utolsó használható windows)

- a magyar programozók; hát izé, mindenütt vannak zsenik is és sarlatánok is.

Nem igazán értem a nyavajgást, a java lefele kompatibilis, tehát egy 1.8-as java-val simán mennie kell az 1.6-os kódnak is (amennyiben nem használtak restricted api-t) ráadásul pont a java-nál nem gond, ha egyszerre n verzió fent van a gépen, egyszerűen csak máshonnan indítod, és ennyi.

Pontosan milyen bug miatt? Azt tudom hogy az Java SE 7 GA verzióban volt egy igen komoly loop optimization bug, aminek következtében a helyesen megírt kódok szénné fagytak, de nagyon gyorsan megérkezett rá a patch. Rendes helyen még az alkalmazások tesztje sem futott ki mialatt ez lezajlott.

--
arch,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Fentebb úgy tűnt, szerinted nincs baj a Java-val, erre ez az utolsó félmondat pedig mintha az ellenkezőjét sugallaná. Nem értem. Lehet Java-appletteket írni? Hát akkor? Van aki ír is. Máshol a webstartos indítást javasolta valaki elfelejteni. A harmadik gárda azt javasolja, hogy ne használjunk Javat szerver oldalon. Ha ezeket mind figyelembe veszem, akkor az jön ki, hogy ne használjunk Javat sehogyan sem (igen tudom, van ilyen osztály is).

A java nem csak egy nyelv, hanem egy nagy ecosystem. Ennek vannak jó részei, meg kevésbé jó, esetenként elavult részek. Ez utóbbira a példa a java applet: régen még mi is fejlesztettünk intranetes rendszerbe java appletet, de akkor még a html css javascript nagyon gyenge volt. Most már ott tartunk, h standard appot irunk át gwtbe. Ezt hozta a fejlődés.

Nem vagyok otthon benne, de nem elképzelhető, hogy 1.6-ban volt valami, 1.7-ben közölték, hogy elavult, majd 1.8-ban megszüntették? (Csak mert ebben az esetben már nem igaz amit állítasz.)
Én pedig mindenféle elméletieskedés hellyett a gyakorlati tapasztalatommal jövök, miszerint én elhiszem, hogy kompatibilis, de időnként mégis gond van a verziókülönbségekből. Persze nem tudok most pontos appot előkeresni, de párszor futottam bele ilyesmibe.
Ráadásul még mindig arról van szó, hogy pl. pár hónapja szembejött egy szép nagy szervezetnél az, hogy az egyik alkalmazásuknak 1.5-ös Java kellett. E miatt *csak* az volt a gépen. Ellenben minta az AbevJava (OK: AnyK) azzal nekem nem futott volna. Tehát a "futtatáshoz Java kell", az azért így kicsit tág fogalom, bőven lehet hibaforrás.

Ha emlékszel, mit szokott mondani Sziporka Hebrencs: Ennek működnie kellene! (It should work with no problems.)...

Természetes igény lenne, hogy az új futtató elvigye a régi programokat, oszt mégis folyton olyan alkalmazásokról hallunk, amikhez egy bizonyos verzió kell, mert különben nem garantált a működés... (persze azzal sem garantált, írja az apróbetűs rész) Aztán ha a derék usernek egyszerre két ilyen alkalmazása van, akkor így járt... És persze ha nem a legújabb verziót használod, akkor a biztonsági lyukak miatt aggódhatsz, ha a legújabbat, akkor az experimentális feature-ök miatt.

Egyébként lehet, hogy igazságtalan voltam a Windows-hoz, mert azon kívül, hogy kényszeresen változtatgatják a look'n'feel-t, és hülyeségekre bazarolják a CPU-t (Vista minialkalmazások, térben forgó ablakok...) igenis szoktak ügyelni a bináris kompatibilitásra... (legalább a plain Windows API-t illetően, annál bonyolultabb eszközt sosem használnék).

A magyar programozók meg... (nem tudom, hogy a külföldiek különbek-e) nagyon sok köztük az olyan, aki egy bizonyos eszközt/környezetet/megtanult, és igénye sincs másra, a főnökei sem várják tőle... Ha mondjuk ő ismeri az IBM MQS-t, akkor nyakra-főre azt kell használni... Ha megcsinált egy webes alkalmazást, ami csak az X böngésző Y verziójával jó, akkor nem kezdi el keresni a javítás lehetőségét, hanem kötelezővé teszi a X böngésző Y verziójának használatát.

( gelei v | 2014. 08. 28., cs – 15:59 )

Még sosem találkoztam ilyesmivel, pedig dolgoztam olyan cégnél, ahol kb. 400 munkaállomásra (kb. 8-10 különböző konfiguráció/image kombó, a gépek a vállalhatatlanul elavulttól a sci-fi kategóriáig) volt telepítve ÁNYK, különböző Windows és Java verziókkal. Bár az igaza, hogy J8 még nem volt nálunk.

Hetes Javával is próbáltad?

( uid_7086 | 2014. 08. 28., cs – 16:12 )

Első ránézésre egy tipp: 8-as javat felejtsd el! Túl friss.

( _Franko_ v | 2014. 08. 28., cs – 16:15 )

Nagyon sok dolog változott a Java SE 8 működését tekintve az előző kiadáshoz képest, ami gond lehet. Szerintem próbálj meg visszaállni Oralce Java SE 7-re és ha akkor is jelentkezik, akkor valami nagyon el van konfigurálva.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( SkyNET | 2014. 08. 28., cs – 22:15 )

Lehet, hogy rosszul tudom, server-classnak 2 mag és 2GB RAM felett tekinti a launcher a gépet, csak ezek fölött indít server VM-et. Le is tudod ellenőrzni, mekkora heaped van.

C:\Users\user>java -XX:+PrintFlagsFinal -version | find "MaxHeapSize"
uintx MaxHeapSize := 4290772992 {product}
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

Nálunk a járulék bevallás ellenőrzésnél nem server-class irodai gépen erre az volt a megoldás, hogy az ányk home könyvtárában van egy setenv.bat fájl, annak a @SET MEMORY_OPTS= sorába be kell írni mekkora legyen a max heap pl. -Xmx512m vagy több is akár.

Ez érdekes itt nálam Client hotspot indul a 2 mag 1GB hozzárendeléssel.


$ cat /proc/cpuinfo
processor : 0
...
processor : 1


$ java -XX:+PrintFlagsFinal -version | grep MaxHeapSize
uintx MaxHeapSize := 262144000 {product}
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)

viszont java -server is ugyanolyan értékeket mutat. A irodai winxp pc-n pedig 64M volt a heap client VM-re (1.7), azért kellett növelni az Xmx-el a felső határt.

Ez megint ilyen holisztikus megközelítés. Az érvelésed szerint a Python értelmező, a Flash lejátszó, a .NET runtime is "okozhat $valamilyen problémákat", de gondolom a valamilyent nehéz lenne korrektül kifejteni.
Ja és egy tipp: 64 biten a -server flag default Java-nál.

--
arch,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Te most miről is beszélsz?
A 64 bites részt értem, ez ha igaz, megmagyarázza, hogy nálam miért fut szerverként.
Virtualizációnak meg nézz utána, ha nem hiszed el, hogy két vm egymásban nem mindig szerencsés, mondhatni, elég gyakori, hogy elhajt a búsba amikor egy vm-et hostként próbálsz használni.

Ui: nem, nem azt mondom, hogy guestben nem fut a jvm, csak azt, hogy lehet oka ellenőrizni és alkalmazkodni adott környezethez.

( sz332 v | 2014. 08. 31., v – 19:56 )

Egy log-ot esetleg szúrj be, hogy meg tudjuk nézni, illetve javallott a 7-es java használata, amíg a 8-asnál nem tartanak legalább u20-nál...

A -Xmx-et esetleg érdemes lenne felnyomni úgy 1024m-re...

http://stackoverflow.com/questions/1393486/error-java-lang-outofmemorye…

Ezzel lehet még próbálkozni... a lényeg itt van:

"The GC throws this exception when too much time is spent in garbage collection for too little return, eg. 98% of CPU time is spent on GC and less than 2% of heap is recovered.
This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small."