|
Ez a nagyon hosszú oszlopsor (1. rész, 2. rész, 3. rész, 4. rész, 5. rész y 6. rész) itt vége lesz. Kiterjeszteném a szemantikus asztal egyéb elemeit, de nem leszek képes megválaszolni azokat az érveket, amelyek rengeteg, az interneten szétszórt útmutatóban vannak feltüntetve, amelyek tanácsot adnak a szemantikus asztal kikapcsolásának legjobb módjairól, mert emésztenék a memóriát. darabonként. |
Ne aggódjon, az egyetlen módja annak, hogy olyan rögzítést készítsen, amelyet egy olyan rendszeren láthat, ahol a Nepomuk megfelelően működik, mint az enyém, ugyanúgy jár el, mint én: töltsön le 1 GB szöveges PDF fájlokat, amelyek 13 millió címmel rendelkeznek, és futtassa azokat a Nepomuk indexelőjén keresztül (nem vicceltem, megtettem). Azt sem gondolom, hogy Ön szó szerint több ezer oldalas PDF-eket kezel (ügyvédi munkámhoz a chilei alkotmány történetét kell kezelnem, 10 db, egyenként 1.200 oldalas szöveget tartalmazó PDF-fájlokat), ezért helyesen konfigurált rendszerben soha nem látom ezt a fogást.
Most kezdjük komolyan és technikailag. Nem itt az ideje egy újabb oktatóanyagnak a „Letiltás a Nepomukról, hogy jó teljesítményt nyújtson”, hanem az első internetes oktatóanyag, amely arról szól, hogy „hogyan lehet nagyszerű teljesítményt elérni Nepomukkal”. Figyelj.
előfeltételek
Lehet, hogy ennek elsőnek kellett volna lennie az útmutatómban, és sajnálom, de csak meg kellett indokolnom, hogy miért aktiválom a Nepomukot (amit az első hat részletben tettem), mielőtt elmondtam volna, hogyan kell helyesen aktiválni. Tehát sétálunk azon, amire szükségünk van, majd konfiguráljuk.
Először is szigorúnak kell lennünk az általunk használt disztribúciókkal kapcsolatban. Itt nagyon világos követelmények vannak: az elavult szoftvert beépíteni szerető terjesztések nem működnek a KDE számára, és ez sajnos magában foglalja a Debiant is. Rex Dieter, a Fedora KDE csapatának vezetőjének hatalmas munkájának köszönhetően számos csomag található a KDE 4.10-tel a Red Hat Enterprise Linux 6 számára, így ha KDE-re és stabil disztribúcióra van szükség, akkor az opció az RHEL 6, vagy egy RHEL 6 klón, mint a CentOS, engedélyezve az adott tárat.
Másodszor, figyelni kell a KDE csomagolására, mert a KDE rendkívül érzékeny a rossz csomagolásra. Egészen a közelmúltig Kubuntu arról volt híres, hogy groteszk csomagolási hibákat követett el, összekeverte a szükséges csomagok nem támogatott verzióit, ami borzalmas Kubuntu élményt eredményezett, és az emberek azon tűnődtek, vajon miért Nepomuk olyan lassú és éhes az emlékezetben, ha valójában a csomagoló hibája volt. A Nepomuk és az Akonadi átviteli lánc ez (a project.kde.org projektnevekkel és a legújabb verziókkal)
kdelibs (4.10.4)
nepomuk-mag (4.10.4)
kde-futásidejű (4.10.4)
nepomuk-widgetek (4.10.4)
megosztott asztali ontológiák (0.10.0)
szoprán (2.9.1.)
akonadi (1.9.2)
Figyelem az utolsó 3-ra: ezek nem függenek az alkalmazott KDE verziótól, és a legutolsónak is elérhetőnek kell lenniük, még akkor is, ha stabil pontot használunk. A szabály a következő: A KDE ezeknek a csomagoknak a legújabb stabil verzióját használja a stabil ágában, a git pillanatképeket pedig a béta ágakban. Sok extra KDE frissítési adattár frissíti a KDE-t, de ez az utolsó három csomag nem, ami komoly problémákat okoz.
Ehhez jön még a nemrég Nepomuktól elvett Strigi, amely igazi fejfájást okozott mindazoknak, akik megpróbálták csomagolni. Az új verziókat nem reklámozták megfelelően, és az Ubuntu sokáig nem csomagolta be ennek a programnak az új verzióit, olyannyira, hogy Sebastian Trüg blogján nagy gondot kellett okoznom a javítás érdekében. Szerencsére ez a probléma nagyrészt elmúlt, és a Strigi már nem nagyon frissül, ami megszünteti a csomagolási problémát.
Ezért a Chakrát ajánlom jó indexeloszlásként. Manuel Tortosa, a Chakra KDE csomagolója mindezt tudja, ezért jó a csomagok minősége, és a Nepruk és Akonadi mellett, a csakra alatt végzett tapasztalatok is jóak. A csakrának vannak komoly korlátai, például nem csomagolja be azokat a programokat, amelyek alapértelmezés szerint a GTK + -tól függenek, de ez jó kezdet.
Továbbá, amint azt a következőben látni fogjuk, nagyon ajánlom egy disztribúciót, amely már átállt a MySQL-ről a MariaDB-re. Majd később meglátjuk.
A talaj előkészítése
Miután megbizonyosodtunk arról, hogy minden előfeltételnek eleget tettünk, és amíg tiszta rendszerünk van, néhány változtatást meg fogunk tenni az alapértelmezett beállításokon.
Akonadi
A következő sorokat a .local / share / akonadi / mysql.conf fájlba helyezzük.
sync_binlog = 1 innodb_flush_log_at_trx_commit = 1
Ha ez a fájl nem létezik, elindítjuk az Akonadit annak létrehozására, majd bezárjuk. Konzolon:
akonadictl start akonadictl stop
Ezért? A MySQL (vagy MariaDB) az Akonadit támogató adatbázis, és a MySQL nem szereti a hirtelen megszakításokat. Bármely rendszer összeomlása vagy áramkimaradás esetén a MySQL hibákat vezet be az Akonadi adatbázisba, és ezek a felhalmozott hibák végül a KMail törlését eredményezik, ami elviselhetetlenül lassúvá teszi. Ezek az opciók azt jelentik, hogy minden tranzakciót azonnal lemezre írnak, minimalizálva az Akonadi korrupciójának kockázatát egy rendszer összeomlása vagy sérülése esetén. Ez az opció hibákat okoz a MySQL bizonyos verzióiban, de kiválóan működik a MariaDB-vel.
mag
A fájlmegfigyelést a maximális szintre emeljük, hogy jelentősen javítsuk a Nepomuk teljesítményét. A /etc/sysctl.conf fájl következő opciója fogja elvégezni a munkát
fs.inotify.max_user_watches = 524288
E két dolog után aktiváljuk Nepomukot. Ez a Rendszerbeállítások | Asztali keresés. Tartsuk a memóriahasználatot az alapértelmezett beállításokon, és kapcsoljuk be az e-mail indexelést. Ne felejtse el megnézni az 1. rész tippjeit arról, hogyan tudjuk felgyorsítani az indexelést, majd ezek után ... nézze meg a többi útmutatót, hogy élvezhesse a szemantikus asztalt!
karbantartás
Mi lenne, ha nem tudnánk elkerülni az Akonadi adatbázis sérüléseit, és a Nepomuk lassan fut? Még mindig van egy védelmi vonal, amelyet a KDE 4.10 megvalósított: a Nepomuk Cleaner, az Akonadi által kevéssé ismert öntisztító eszközök mellett.
$ akonadictl vákuum: "Vákuum" az Akonadi adatbázis. Törekvés alapján értse meg: minden olyan bejegyzést eltávolít, amely nem tükröződik egy erőforrásban.
$akonadictl fsck: Kísérletek kijavítani az Akonadi adatbázis sérüléseit. Ez nem mindig működik, ezért eleve meg kell akadályoznia őket. Hogyan? Azokkal a lehetőségekkel, amelyeket már láttunk.
$nepomukcleaner: Ez egy szkriptkészlet, amelyet Vishesh Handa készített a Nepomuk adatbázis megtisztítására, amelyet grafikus interfésszé alakított át. Nyomd meg a "Start" gombot, és felejtsd el. A program futtatása kötelező, ha frissíti a KDE verzióját.
Az összes csecsebecsével, 64 bites rendszeren és kísérleti Akonadi erőforrásokkal Nepomuk és Akonadi összege körülbelül 350 MB RAM-ot emészt fel. Sokak számára sok, de véleményem szerint megfelelő a megszerzett óriási tulajdonságokhoz.
De Nepomuk még mindig túl lassan fut a kedvem szerint. Mit csinálok?
Várj mig. A KDE 4.11 magában foglalja a Nepomuk teljesítményének brutális növekedését. Ez nem bármiféle túlzás: Vishesh Handa adatai szerint a KDE 5 teljesítményének ötszöröséről beszélünk írásban az adatbázisba, és több mint hétszer az olvasásról, mindez átlagosan. A KDE 4.10-ben észrevehető változások hatalmasak, és lehetővé teszik a Nepomuk alkalmazását alternatívaként az adatbázisokat igénylő alkalmazások számára.
Ezenkívül az Akonadi-Nepomuk csatlakozó helyes indítását megakadályozó hiba már javításra került a 4.11 ágban, és a Nepomuk tisztító nagy fejlesztéseket fog látni. Új Office fájlindexelőnk lesz, és élvezhetjük a később kiderülő egyéb eszközöket.
Remélhetőleg ez az útmutató - ismétlem - az egyetlen, amelyet megtalál, hogyan lehet elérni a látványos teljesítményt az aktivált Nepomuk segítségével, segít a zökkenőmentes konfigurálásban, amely lehetővé teszi, hogy a korábbi részletekben látottakat és még sok minden mást is megtehessen. Köszönöm, hogy követte ezeket a részleteket, és nagyon köszönöm Pablo Castagninónak, hogy kiadta ezt a sorozatot. Hamarosan találkozunk.