|
Denna mycket långa serie kolumner (del 1, del 2, del 3, del 4, del 5 y del 6) kommer att få ett slut här. Jag skulle kunna utöka andra delar av det semantiska skrivbordet, men jag kommer inte att kunna svara på argumenten som ges i massor av guider utspridda över Internet som ger råd om de bästa sätten att inaktivera det semantiska skrivbordet, eftersom det skulle äta upp minne av biten . |
Oroa dig inte, det enda sättet du kan fånga som den du ser i ett system där Nepomuk fungerar som jag, är att göra detsamma som jag: ladda ner 1 GB i PDF-textfiler som har 13 miljoner av adresser och kör dem genom Nepomuk-indexeraren (inte skojar, det gjorde jag). Jag tror inte heller att du hanterar PDF-filer på bokstavligen tusentals sidor (för mitt arbete som advokat måste jag hantera den chilenska konstitutionens historia, 10 PDF-filer med 1.200 sidor vardera), så i ett korrekt konfigurerat system borde du inte se detta fånga någonsin.
Låt oss nu bli seriösa och tekniska. Det är inte dags för ännu en handledning om ”inaktivera Nepomuk för att få bra prestanda”, utan för den första självstudien om “hur man får bra prestanda med Nepomuk på”. Var uppmärksam.
förutsättningar
Kanske borde detta ha kommit först i min guide, och jag är ledsen, men jag var bara tvungen att motivera varför jag aktiverade Nepomuk (vilket var vad jag gjorde under de första sex delarna) innan jag berättade hur man aktiverar det korrekt. Så vi tar en rundtur i vad som behövs och sedan konfigurerar vi.
Först och främst måste vi vara strikta med de distributioner vi kommer att använda. Här är mycket tydliga krav: distributioner som gillar att införliva föråldrad programvara fungerar inte för KDE, och det inkluderar tyvärr Debian. Tack vare Rex Dieters enorma arbete, ledare för Fedora KDE-teamet, finns det en uppsättning paket med KDE 4.10 för Red Hat Enterprise Linux 6, så om du behöver KDE och en rockstabil distribution är alternativet RHEL 6, eller en RHEL 6-klon som CentOS, där förvaret är aktiverat.
För det andra måste du vara uppmärksam på hur KDE förpackas, eftersom KDE är extremt känslig för dålig förpackning. Fram till nyligen var Kubuntu beryktad för att göra groteska förpackningsfel, blanda versioner av paket som inte stöds, vilket resulterade i en hemsk Kubuntu-upplevelse och folk undrade varför Nepomuk var så långsam och minnes hungrig när det faktiskt var förpackarens fel. Överföringskedjan Nepomuk och Akonadi är detta (med projektnamn från projects.kde.org och senaste versioner)
kdelibs (4.10.4)
nepomuk-kärna (4.10.4)
kde-runtime (4.10.4)
nepomuk-widgets (4.10.4)
shared-desktop-ontologies (0.10.0)
sopran (2.9.1)
akonadi (1.9.2)
Uppmärksamhet på de sista 3: de beror inte på vilken KDE-version som används, och måste vara den senast tillgängliga, även när du använder en stabil punktversion. Regeln är: KDE använder den senaste stabila versionen av dessa paket i sin stabila gren och git ögonblicksbilder i sina betagrenar. Många extra KDE-uppdateringsförvar uppdaterar KDE, men inte dessa tre sista paket, vilket orsakar allvarliga problem.
Till detta kommer Strigi, nyligen hämtad från Nepomuk, vilket var en riktig huvudvärk för alla som försökte packa den. Nya versioner annonserades inte ordentligt och Ubuntu packade inte nya versioner av detta program på länge, så att jag var tvungen att göra ett krångel på Sebastian Trügs blogg för att få det fixat. Lyckligtvis är detta problem i stort sett över och Strigi uppdateras inte mycket längre, vilket eliminerar förpackningsproblemet.
Det är därför jag rekommenderar Chakra som en bra indexfördelning. Manuel Tortosa, KDE-förpackaren för Chakra, vet allt detta, och därför är paketkvaliteten bra, och upplevelsen med Nepomuk och Akonadi, under Chakra, är också bra. Chakra har några allvarliga begränsningar, som om det inte är standard för paket som är beroende av GTK +, men det är en bra start.
Som vi kommer att se vidare rekommenderar jag starkt en distribution som redan har bytt från MySQL till MariaDB. Vi får se varför senare.
Förbereder marken
När vi väl har säkerställt att vi uppfyller alla förutsättningar, och så länge vi har ett rent system, kommer vi att göra några ändringar i standardinställningarna.
Akonadi
Vi kommer att placera följande rader i .local / share / akonadi / mysql.conf-filen.
sync_binlog = 1 innodb_flush_log_at_trx_commit = 1
Om den här filen inte finns startar vi Akonadi för att skapa den och sedan stänger vi den. På konsolen:
akonadictl start akonadictl stop
För detta? MySQL (eller MariaDB) är databasen som stöder Akonadi och MySQL gillar inte plötsliga avbrott. I händelse av systemkrasch eller strömavbrott kommer MySQL att införa fel i Akonadi-databasen, och dessa fel, ackumulerade, kommer att sluta lossa KMail, vilket gör användningen outhärdligt långsam. Dessa alternativ innebär att varje transaktion omedelbart skrivs till disk, vilket minimerar risken för korruption i Akonadi i händelse av systemkrasch eller korruption. Det här alternativet orsakar fel med vissa versioner av MySQL, men det fungerar bra med MariaDB.
Kärna
Vi kommer att höja filövervakningen till maximal gräns för att väsentligt förbättra Nepomuks prestanda. Följande alternativ i /etc/sysctl.conf-filen gör jobbet
fs.inotify.max_user_watches = 524288
Efter dessa två saker kommer vi att aktivera Nepomuk. Detta görs i Systeminställningar | Skrivbordssökning. Låt oss behålla minnesanvändningen vid standardinställningarna och aktivera e-postindexering. Glöm inte att kolla in tipsen från del 1 om hur vi kan påskynda indexering, och efter det ... kolla in resten av guiderna för att njuta av det semantiska skrivbordet!
underhåll
Vad händer om vi inte kunde förhindra korruption i Akonadi-databaser och Nepomuk går långsamt? Det finns fortfarande en försvarslinje som KDE 4.10 implementerade: Nepomuk Cleaner, förutom de lite kända självreningsverktygen som Akonadi har.
$ akonadictl vakuum: "Vakuum" Akonadi-databasen. Genom aspiration, förstå: alla poster som inte återspeglas i en resurs tas bort.
$akonadictl fsck: Försök att åtgärda korruptionen i Akonadi-databaser. Detta fungerar inte alltid, så du måste förhindra att de händer i första hand. Hur? Med de alternativ som vi redan såg.
$nepomukcleaner: Det är en uppsättning skript som utarbetats av Vishesh Handa för att rengöra Nepomuk-databasen, som han konverterade till ett grafiskt gränssnitt. Tryck på "Start" -knappen och glöm det. Det är obligatoriskt att köra programmet om man uppdaterar KDE-versionen.
Med alla prydnadssaker, på ett 64-bitars system och med experimentella Akonadi-resurser, förbrukar summan av Nepomuk och Akonadi cirka 350 MB RAM-minne. Mycket för vissa, men tillräckligt, enligt min åsikt, för den enorma funktionalitet som uppnås.
Men Nepomuk går fortfarande för långsamt efter min smak. Vad jag gör?
Vänta lite. KDE 4.11 innehåller brutala prestationsökningar för Nepomuk. Detta är inte någon överdrift: enligt Vishesh Handas siffror talar vi om fem gånger KDE 5: s prestationer skriftligen till databasen och mer än 4.10 gånger vid läsning, allt detta i genomsnitt . Förändringarna i KDE 7 är stora och gör att Nepomuk äntligen kan användas som ett alternativ för de applikationer som kräver databaser.
Dessutom har felet som förhindrar korrekt start av Akonadi-Nepomuk-anslutningen redan åtgärdats i filial 4.11, och Nepomuk-rengöraren kommer att se stora förbättringar. Vi kommer att ha en ny Office-filindexerare och vi kommer att kunna njuta av andra verktyg som kommer att avslöjas senare.
Förhoppningsvis den här guiden, upprepar jag, den enda du hittar om hur du uppnår spektakulär prestanda med Nepomuk aktiverad, hjälper dig att ha en smidig installation, så att du kan göra det vi såg i tidigare delbetalningar och mycket, mycket mer. Tack för att du följde mig genom alla dessa delbetalningar och ett stort tack till Pablo Castagnino för att du publicerade den här serien. Ses snart.