Van egy Mongo szolgáltatásom, amellyel több állomás interakcióba lép. Az a gazdagép, amelyen a Mongo szolgáltatás fut, egészen különleges – 3 TB RAM-mal rendelkezik. Ez a gazdagép azonban időszakos buszhiba-válaszokat is dob. Ha buszhiba lép fel a Mongo szolgáltatási folyamaton belül, a szolgáltatás leáll, és az összes olyan zeller (Python) folyamat, amely kölcsönhatásba lép az erőforrással, kiszolgálja a Connection Refused válaszokat.
Van-e mód a Mongo szolgáltatás engedélyezésére hogy valahogy helyreálljon egy buszhibából? A szilánkosodás segíthet ebben a problémában? Van-e más lehetséges megoldás a buszhibára, amelyet az alkalmazás konfigurációs szintjén el lehet végezni? Hálás lennék minden olyan javaslatért, amelyet mások felajánlhatnak ebben a kérdésben!
A Mongo-t forrásból építettem a RedHat-ra, így bármilyen friss verziót használhatok, ha ez segít. A jelenleg telepített verzió a 3.6.4.
Megjegyzések
- A buszhibák valamilyen folyamatból származnak, amely megpróbálja megszüntetni a nem ott lévő RAM-ot (nem lehet megoldani). Gondolom, meg kell vizsgálnia a HW / SW kompatibilitás.
- @dezso nem lehet megoldani ezt a problémát az alkalmazás szintjén? ' Nem befolyásolhatom a hardvert ebben az esetben, de konfigurálhatom a mongo alkalmazás …
- Nos, ahogy hangzik, a MongoDB nem tudja megfelelően kezelni (címezni) a memóriát. Ezt alig lehet kijavítani a beállítások módosításával (de ezt úgy mondom, hogy nem ismerem a MongoDB-t). ' azt javaslom, hogy nyissanak ki egy problémát a fejlesztőknél, lehet, hogy jobb ötletük van, mint itt bárki.
- @duhaime, Frissíthetnék a " Busz hiba ?. Szoftverszintről vagy hardvercímkéről származik. Ellenőrizte a " smartmontools " funkciót linuxos környezetben?
- @MdHaidarAliKhan Úgy gondolom, hogy ez a buszhiba a hardveres szinten, de ' szeretném elkapni a kivételt az alkalmazásrétegen …
Válasz
Buszhiba kezelése a Mongo szolgáltatásban
MongoDB dokumentáció itt Hasznos lenne a smartctl futtatása is (a smartmontools része) az SMART hardverhibák ellenőrzéséhez:
sudo smartctl -a /dev/sdb Még akkor is futtathatja a Linux rendszert, fsck segédprogramot használ a Linux fájlrendszerek ellenőrzésére és javítására (ext2, ext3, ext4 stb.).
Attól függően, hogy mikor volt utoljára fájl a rendszer ellenőrzése megtörtént, a rendszer a fsck fájlt futtatja indítási idő alatt annak ellenőrzésére, hogy a fájlrendszer konzisztens állapotban van-e. A rendszergazda manuálisan is futtathatja, ha probléma merül fel a fájlrendszerekkel.
Ügyeljen arra, hogy az fsck fájlt leválasztatlan fájlrendszeren hajtsa végre az adatok sérülésének elkerülése érdekében. problémák.
Válasz
Busz hiba leggyakrabban a programhiba, ebben az esetben maga a MongoDB, vagy ritkán hardverprobléma. Mint ilyen, először meg kell próbálni a frissítést a legújabb stabil verzióra. Ha a probléma továbbra is fennáll, akkor nem sokat tehet ez ellen azon kívül, hogy hibajelentést küld a Mongónak.