A nagykönyv szerint ugye 50MB RAM/user a szükséges. De úgy tűnik, ez messze nem minden funkciónál valós, mert nekem pl. a tesztnél omlik csak össze az adatbázissal a kapcsolat, egyébként jóval több user is dolgozhat. Nincs vmi részletesebb információ az egyes funkciók memóriaigényéről?
Az "összeomlások" oka nem feltétlenül a RAM fogyása, hanem az adatbázis pillanatnyi túlterhelése.
Az alábbi oldalt érdemes tanulmányozni, és szükség esetén finomhangolni a rendszert: http://docs.moodle.org/en/Performance
Érdemes még körülnézni a Moodle ► Adminisztráció ► Szerver ►Teljesítmény oldal beállításai között is.
Vágvölgyi Csaba
Az alábbi oldalt érdemes tanulmányozni, és szükség esetén finomhangolni a rendszert: http://docs.moodle.org/en/Performance
Érdemes még körülnézni a Moodle ► Adminisztráció ► Szerver ►Teljesítmény oldal beállításai között is.
Vágvölgyi Csaba
Köszönöm, bár ez így első olvasatra elég meredek. Nem kétlem, hogy ez az, túlterhelés, de mégis: összeomlás a vége és nem csak az adott moodle portál, de a többi honlap is bedől ilyenkor, ha csak nem kerül sor rebootra.
Ha jutok is valamire (amit kétlek), van valami lehetőségem embermentes terhelés-tesztre?
Ha jutok is valamire (amit kétlek), van valami lehetőségem embermentes terhelés-tesztre?
Sziasztok!
Nálunk is mostanában volt olyan hibaüzenet, hogy túl sok felhasználó van bejelentkezve. Ez kb. 15-20 volt. Kicsit furcsának találom, mivel már 120 feletti user is volt egyszerre bejelentkezve. Kevés szabad RAM lenne a szerveren?
Üdv: Zoli
Nálunk is mostanában volt olyan hibaüzenet, hogy túl sok felhasználó van bejelentkezve. Ez kb. 15-20 volt. Kicsit furcsának találom, mivel már 120 feletti user is volt egyszerre bejelentkezve. Kevés szabad RAM lenne a szerveren?
Üdv: Zoli
Mint minden esetben a probléma összetett . Az most biztos számomra is, hogy kevés a RAM a userek és a kliensgépek számához. Pl. a labor, amihez ki lett építve, időközben vagy megduplázódott gépszámában, de ugye a szerver párhuzamos fejlesztése már nem haladt ezzel együtt. A RAM igény még a régi méretekhez volt kitalálva ... (tegyek bele RAM-ot, ez én is tudom, de ez nem ennyire egyszerű mindig ...)
De most már attól félek, hogy hiába kerül bele - vmi folytán majd -, esetleg RAM pluszban, akkor se oldódnak meg a problémák. Illetve addig is vhogy ha lehetne optimalizálni, játszadozni a meglevő keretek között. Ez előre tekintve sem árthat, oda jutottam most.
Gondolom, pl. a tesztírás az valhogy jobban terheli az adatbázis szervert. Nem tudom, lehet-e pl. valahogy elhúzódó tesztmegnyitási időponttal ezen segíteni? Mert így év végén, javítandó zh-k és félévi feladatok között odaülni a gép elé és azt próbálgatni, hogy ha így állítok az SQL-ben, akkor ez van, ha úgy, akkor meg amaz, biztos nem működik (idő[hiány]). Ezért gondoltam, hogy hátha van valami információ arról, hogy melyek azok a MOODLE-s funkció, amelyek erőforrásigényesebbek, amelyek szűk keresztmetszetet jelentenek, ahol finomab játék- és mozgástér van.
De most már attól félek, hogy hiába kerül bele - vmi folytán majd -, esetleg RAM pluszban, akkor se oldódnak meg a problémák. Illetve addig is vhogy ha lehetne optimalizálni, játszadozni a meglevő keretek között. Ez előre tekintve sem árthat, oda jutottam most.
Gondolom, pl. a tesztírás az valhogy jobban terheli az adatbázis szervert. Nem tudom, lehet-e pl. valahogy elhúzódó tesztmegnyitási időponttal ezen segíteni? Mert így év végén, javítandó zh-k és félévi feladatok között odaülni a gép elé és azt próbálgatni, hogy ha így állítok az SQL-ben, akkor ez van, ha úgy, akkor meg amaz, biztos nem működik (idő[hiány]). Ezért gondoltam, hogy hátha van valami információ arról, hogy melyek azok a MOODLE-s funkció, amelyek erőforrásigényesebbek, amelyek szűk keresztmetszetet jelentenek, ahol finomab játék- és mozgástér van.
Amit saját tapasztalatból mondani tudok, hogy az adatbázis finomhangolására mindenképpen érdemes egy kevés időt fordítani. Nálunk PostgreSQL szolgálja ki a Moodle-t. Ott arra kell mindenképpen figyelni, hogy rendszeresen legyen vacuum-ozás, vagyis a törölt rekordok ténylegesen törlésre kerüljenek. Emiatt korábban az általad említett helyzet ált elő nálunk is. Akkor gyors megoldás volt a memóriabővítés, de végleges megoldást nem az hozott.
A Csaba által ajánlott leírásban szerepel, hogy a swap mérete a fizikai memória négyszerese legyen. Szerintem ez túlzás, ráadásul egy lassabb háttértár esetében nem a virtuális memória mérete okoz majd gondot, hanem a lemezek kezelése. Ilyenbe is belefutottam, amikor is a lassú lemezegységkezelés miatt a swap-elés annyira leterhelte a rendszert, hogy még konzolon is alig lehetett bejelentkezni.
Érdemes tehát a lemezegységek beállításait is felülvizsgálni (pl.: hdparm segítségével).
A Csaba által ajánlott leírásban szerepel, hogy a swap mérete a fizikai memória négyszerese legyen. Szerintem ez túlzás, ráadásul egy lassabb háttértár esetében nem a virtuális memória mérete okoz majd gondot, hanem a lemezek kezelése. Ilyenbe is belefutottam, amikor is a lassú lemezegységkezelés miatt a swap-elés annyira leterhelte a rendszert, hogy még konzolon is alig lehetett bejelentkezni.
Érdemes tehát a lemezegységek beállításait is felülvizsgálni (pl.: hdparm segítségével).