1. Tudásbázis
  2. Telepítés, migráció, beállítások
  3. 500 Internal Server Error - Semmi sem segít!!!!!

500 Internal Server Error - Semmi sem segít!!!!!

Beküldte NetMajom - 2014. január 11. 20.35
NetMajom képe

Sziasztok

Oldalt migráltam dedikált szerverre. Meg is történt, az oldal működik, de egy nagyobb műveletnél, mint például cache ürítés, stb... 500-as Internal Server Errorral elszáll.
A témában nagyon sok tanács van a neten, php memórianövelés, execution time növelés, .htaccess file -ban followsymlinks kikommentelése, chmod beállítása a könyvtáraknak, stb... Nagyon hasznos tanácsok, de sajnos egyik sem vált be.
Már nem tudok mihez nyúlni, mert már az összes 5let elfogyott... Valaki beleütközött már ebbe a hibába?

Drupal verzió: 
7.x
Fórum: 
Telepítés, migráció, beállítások
nevergone képe

Beküldte nevergone - 2014. január 11. 20.59

A 500-as hiba mindig szerver-oldali hibát jelez. Szolgálatót (vagy a rendszergazdát) kérdezd meg, esetleg kérj PHP logot tőle.

1
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

NetMajom képe

Beküldte NetMajom - 2014. január 11. 22.45

Ebben biztos voltam hogy a szerveren valami nem stimmel.
A szerver mivel az enyém, pontosabban bérlem, ezért nem tudok kit megkérdezni, ezért írtam ide a közösségbe...

0
-1
nevergone képe

Beküldte nevergone - 2014. január 11. 22.52

Igen, így viszont kérdezd meg a rendszergazdát. Én legalábbis csak úgy bérelnék szervert, ha rendelkezésemre állnának az üzemeltetéshez szükséges erőforrások, akár új funkciókhoz, akár hibajavításhoz.

1
-1

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

NetMajom képe

Beküldte NetMajom - 2014. január 11. 23.27

Ez nem lehet igaz.... Állandóan csak a kioktatás? Csak ebbe a magyar közösségbe olvasgatva a fórumtémák között találok lenéző, vagy kioktató válaszokat. Nem egy ilyen témával találkoztam már itt. Természetesen mindenki elkezdte valahol a dolgokat, és nem Einsteinként született meg. Az internet, és a "közösségek" megjelenésével táborok alakultak, akik összedobják amijük van, és segítenek egymásnak (vagy lehet ez Utópia lenne?).
Ebbe a drupal közösségbe, és a fórumokba legtöbben hibával, problémával, vagy észrevétellel írogatnának (szerintem!!!). Mivel már 2 napja ezzel a hibával küzdök, segítség nélkül, pontosabban a google-t használok, számos dolgot eddig átállítottam, valamint hála a drupal.org felhasználói fórumozásának, amiben sok hasznos dolgot találtam, de a hiba fennáll.

Ez a különbség a magyar, és a külföldi emberek között. Nem is tudom mit képzeltem, hogy ide írtam hiba végett.
Itt csak kioktatást fogok kapni, és nem tanácsot, amiért hivatott lenne a fórum, míg az angol közösségben adok-kapok jó tanácsot.

Most lehet erre az a válasz fog érkezni hogy "Aki nem tud fára mászni..." de meglátásom szerint 2 fajta ember van akit nem érdekel semmi, és aki "akar" és csinálja, és csinálja, és a tanulni akarás van benne.

Én ha egy hibával találkozom, azt tűzön vízen keresztül megoldom, lehet nem 2 perc alatt, lehet 1 hét alatt, de addig meg nem nyugszom, amíg meg nem tudom oldani, és csak reménykedtem, hogy a drupal.hu közösségében találok valami tippet, ami segíthet hogy ne 1 hét alatt jöjjek rá a hibára.

Elhiszem hogy sok itt a profi és olyan aki álmában is programoz, és üzemeltet, és már csak programkódokat lát színek, és formák helyett. Nagyon becsülöm, és tisztelem ezeket az embereket, mert szerintem csodálatos az a tudásanyag amivel rendelkeznek, és a kalapomat megemelem előttük, de ha lenézzük a másikat, akkor a magyar nyelvű ilyen, és ehhez hasonló közösségek feleslegessé válnak!

0
-1
nevergone képe

Beküldte nevergone - 2014. január 11. 23.41

Nem néztelek le, fel se merült bennem. Az se merült fel bennem, hogy úgy próbálsz üzemeltetni bármit, hogy nincsenek meg a szükséges erőforrások. Ez nem lenézés, ez tény. Ha nem így lenne, akkor menne már az oldalad és nem arra várnál, hogy valaki az általad megadott nulla információból próbálja kitalálni, hogy mi lehet a gond, majd ez alapján szombat éjjel ingyen és bérmentve segíteni neked. Ez is tény.
Egyáltalán nem nézlek le, csak nem értem a hozzáállásodat. Vannak dolgok, amikért fizetni kell: Vagy megtanulod (és akkor az időddel fizetsz), vagy megbízol valakit (és akkor a pénzeddel fizetsz).

Sajnálom, nem tudok segíteni neked. Viszont ha nem tetszik a hazai közösség, szerintem máshol is szívesen várják, hogy segíthessenek a problémád megoldásában.

Ui.: Ha jól látom, akkor „Üzemeltetés, webhosting” nem okoz problémát, legalábbis a korábbi honlapod szerint…

2
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

NetMajom képe

Beküldte NetMajom - 2014. január 12. 00.36

Ez csapatszellem? Ez közösség? Akkor ezek szerint ez a magyar drupal.hu egy hirdetőportál, ahol mindenki beírja a problémáját, és küldik az árajánlatot a "profik", hogy mennyibe kerül a tanácsadás? Akkor én kérek elnézést, hogy nem néztem utána az oldal szabályzatában ennek.
Ha jól tudom, meg nem sürgettem senkit, és ez mivel egy online fórum, aki szombat este feljön ide, valószínű nem a discóbol írogat, vagy pittyeg a telefonja alvás közben.

A hiba megoldása egyszerűbb volt mint gondoltam. php-fpm -et használtam, de most már mod php ruid2 használok, és minden működik.

Egyébként nem a galambot vártam a számba, csupán a közösségek általában úgy működnek, legalábbis az angol drupal.org, hogy a userek ötletelgetnek egymással egy adott hibáról, megoldásról, stb...

Az információ nem nulla amit írtam, a migrálás után jött elő mint hiba, amit írtam is, és a google -ban rengeteg info van, mit kell ilyenkor beállítani/leellenőrizni, ami megtörtént, csak a típus maradt ki ami okozta a hibát. Aki meg szervert telepített a nulláról és összeállított már az lehetséges találkozott már PHP típusbeli hibával migrálást követően.

0
-1
ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 00.37

Én annó a FollowSymk-linkesbe, de az egy kis apache konfigolással megoldódott.

Sajnos az 500-as hiba nagyon sok mindentől lehet. A php error napló állományokat kellene elemezni és abból kideríteni mi okozza a hibát.

Reprodukáld a hibát, közbe pedig figyeld mit művel a naplóban.

Egyéb: Alap MySQL konfigurációt használsz? InnoDB? Mekkora a pufferek mérete? Időtúllépést apache2 oldalon is átállítottad (Apache2+FastCGI) esetén [IPCCommTimeout 301]?

0
0
NetMajom képe

Beküldte NetMajom - 2014. január 12. 00.47

Köszi, működik, már csak sebességbeli feladataim vannak, szerintem picit lassú :D ,de már sehol nem száll el hibával :D

0
0
ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 00.57

Hmm.. egy két gyors tipp hozzá. Szerintem biztos ismersz már egy-kettőt ezekből:

- Memcached, memcached és memcached
- MySQL cserélése MariaDB-re (amennyiben lehetséges, ég és föld)
- Statikus kiszolgálás nginx alól (meglepő de számít) + cdn modul

Sajnos Drupal-nál az adatbázis a szűk keresztmetszet, így azt érdemes tunningolni.

Mi jelenleg azon vagyunk, hogy SSD alá rakjuk be az adatbázis szervert, mert tudjuk, hogy a RAM-nak csak a csillagos ég szab határt :-).

0
0
NetMajom képe

Beküldte NetMajom - 2014. január 12. 01.32

köszi a tippet, a memcached fent van (én nem tapasztalok hihetetlen mértékű gyorsulást a használatát követően de jobb mint a semmi:-) ) , MariaDB-t még nem próbáltam ki, bár már régóta tervezem :)
Most nginx proxy -t használok, kicsit megosztott a véleményem róla, lehet visszatérek sima nginx -re.

Vettem észre, feneketlen az éhsége a Drupalnak RAM terén, egyszerűen hihetetlen néha mennyit zabál...

SSD -t az valóban a legjobb megoldás, csak az árának a csillagos ég sem szab határt :-)

A CDN -t nem használok (még) mivel a legolcsóbb csomag is $49 (amiről tudok) az meg jelenleg nem fér bele a büdzsébe :-) Az ingyenes Content Delivery Network mint például a cloudflare, ahol van alap free csomag, az nem nagy durranás, inkább nem is használom...
Ha nem titok, neked hol van CDN -re előfizetésed?

0
0
szantog képe

Beküldte szantog - 2014. január 12. 02.03

RAMilag ha egy drupal oldal adminként bejelentkezve 200-nál többet kér, ott valami nagyon el van cseszve, érdemes átnézni, hogy mi okozza az étvágyat.

0
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 02.46

Nem értek teljesen egyet. Egy komolyabb oldalnál és 400+ modulnál símán 200+ MB RAM felé megy. Sőt néhány kirívó esetben engedélyeznünk kellett 512-ig, nagyobb műveleteknél (pl. beállítások lekérése). De ez persze admin oldal..

Alapesetben gyorsítótárnál és megfelelő optimalizálás mellett valóban 200 fölé nem nagyon kellene mennie. Az admin mindig is többet fogyasztott, mint az user oldal és ez talán így is van rendjén (több a komplex lekérés).

0
0
ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 03.09

A memcached akkor jó, ha azokra a táblákra van ráállítva amire kell. Nálunk jelenleg az összes "cache_*" meg egy-két olyan tábla amit gyakran szaggat lekérdezés formájában.

Arra persze vigyázzunk, hogy "user" tábla ne nagyon kerüljön bele, mert okoz érdekességeket. :-)

CDN téren nincs előfizetésem. Építettünk egy kifejezetten statikus tartalmat kiszolgáló nginx alapú webszervert és az szolgálja ki a tartalmat (független az oldaltól). Az egyik érdekessége, hogy nagyon részletesen beállítható nginx oldalon az egyes tartalmak cache ideje (annak lejárata), meg persze sok minden más. Másik nagyon jó dolga, hogy támogatja az mp4 h264 streaming-et és jól beállítható (pl. X MB-t töltsön be, majd lassítsa a sávszélességet) vagy, hogy X mp-nél kezdje a video betöltését (ha az user pl előrébb teker), így nem tölti legelőről. A video modullal használjuk.

Egy szóban az NGINX egy kis időráfordítással nagyon jó kis eszköz, agyonkonfigurálható és némileg gyorsabb az apache-nál.

Az SSD ára is már azért megyeget lefelé, mostanába vettem egy SAMSUNG EVO-t (22k körül volt), de alázza a hagyományos merevlemezt. Bár SSD-t szerverbe csak úgy, hogy minimum RAID-elve és gyakori backup, meg összefűzve két adatbázis szerverrel.

MariaDB téren annyit mondhatok, hogy mint sokan tudják a MySQL-t átvette az Oracle. Ez "szép" és "jó", de kicsit "veddmegazoraclet" irányba halad. Ami persze nagyon jó eszköz valóban, álom alá dolgozni, de az ára meg borsos. Szóval a MariaDB több szempontból is jobb a mostani MySQL-nél, sőt.. még kompatibilitási problémával sem kell küszködni, mert felrakod és tökéletesen helyettesíti a MySQL szervert. De ha érdekel a téma olvass utána, szerintem pozitív.

Ha NGINX-re visszaakarsz térni ajánlom figyelmedbe:
https://github.com/perusio/drupal-with-nginx

Kifejezetten Drupal-ra készült konfiguráció. Őszintén megmondom én ebből a konfigurációból csak ollóztam jó dolgokat (tehát nem teljes egészében használom).

0
0
NetMajom képe

Beküldte NetMajom - 2014. január 12. 03.33

Nálam csupán az admin része az oldalnak lassú mert nagyon szerteágazó, és nagyon sok modul van benne, sokan is dolgoznak benne (cikkek írása, bannerek szerkesztése, elemzések készítése, stb...) , úgyhogy maga az admin részével nem igazán vagyok még megelégedve. Továbbá, eléggé teszt megszállott vagyok. a pagespeed insight -al valamint a webpagetest.org -al tesztelem a drupal oldalt, és nagyon szeretném elérni a 95% -ot, ezért folyamatosan buherálom az oldalt, és a szervert.

A link amit adtál, az nagyon jó, egy kincs :-) Köszi szépen...

0
0
ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 03.59

Szívesen, van még egy eszköz (persze számos más is) amivel lehet tesztelgetni az oldal valós sebességét. Apache2 mellé van.

Így néz ki:
$ ab -n 1000 -c 5 http://<webcím>/

Az -n X a lekérések számát határozza meg, a -c X a kapcsolatok számát egyidőben (bővebben man ab).

Egyik munkánkon most hasra pacsi kipróbáltam:

  1. Concurrency Level:      5
  2. Time taken for tests:   13.152 seconds
  3. Complete requests:      1000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      42464000 bytes
  7. HTML transferred:       42033000 bytes
  8. Requests per second:    76.04 [#/sec] (mean)
  9. Time per request:       65.758 [ms] (mean)
  10. Time per request:       13.152 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          3153.12 [Kbytes/sec] received

A lényeg a "Requests per second". Annyit tudj róla, hogy memcache + alap drupal cache aktív az oldalon. Ezek nékül kb. 20-30 req/sec lenne, de már az is jónak számít. A lényeg, hogy tartani lehessen ezt az éréket. :-)

0
0
NetMajom képe

Beküldte NetMajom - 2014. január 12. 04.50

Ez több is mint amit elvárhattam :) Köszi még egyszer... Már csak a "Time to First byte" -ra kell megoldást találnom.....

0
0
chx képe

Beküldte chx - 2014. január 12. 11.02

Az hasznalhatatlan. Kodositesnek (sem) jo. Ha rendesen szeretnel merni akkor jMeter vagy Tsung (ez utobbi foleg).

0
0
chx képe

Beküldte chx - 2014. január 12. 11.01

Ha az *osszes* cache_* tablat betolod memcache-edbe akkor ott olyan pofaraesesek lesznek hogy nocsak. cache_form -ot minimum tessek kivenni onnan!

Masreszt meg en Percona-t hasznalok nem Maria-t, ennek irto sok oka van, de most csak roviden: hidd el hogy az XtraDB jobb a Drupalnak. :)

0
0
ecrazor1911 képe

Beküldte ecrazor1911 - 2014. január 12. 14.31

Nekünk az alábbi konfigurációval fut jó pár oldalunk (settings.php -> Memcache):

  1. //
  2. // Drupal Memcache Configuration
  3. //
  4.  
  5. $conf['memcache_key_prefix'] = $_SERVER['HTTP_HOST'];
  6.  
  7. $conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
  8. $conf['cache_default_class'] = 'MemCacheDrupal';
  9. $conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
  10.  
  11. $conf['memcache_servers'] = array(
  12.   '127.0.0.1:11211' => 'default',
  13.   '192.168.1.110:11211' => 'default',
  14.   '192.168.1.120:11211' => 'default',
  15.   '192.168.1.130:11211' => 'default',
  16.   '192.168.1.140:11211' => 'default'
  17. );

Probléma még nem volt vele. És igen, valóban.. :-) A "cache_form" nálunk is ki van véve a listáról. Hmm.. a Percona nekem még új dolog, az XtraDB-ről hallottam. Köszi, utánanézek. :-)

0
0
szantog képe

Beküldte szantog - 2014. január 12. 01.58

Nem azért kérdeztél?
Én speciel ha kérdezek, azt várom, hogy ki/be/le/fel - oktassanak. Pláne, hogy ezzel a hisztivel sikerült egy abszolútnemdrupal témába belekeménykedni.
//trollolo on/off//

4
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.