Accelerează interogările ownCloud 10 prin gestionarea în siguranță a indexurilor

Pentru ownCloud 10, începeți prin a aplica modificările de schemă livrate de nucleul și aplicațiile instalate, apoi verificați care interogări ale bazei de date sunt de fapt lente. Nu adăugați indexuri orbește și nu presupuneți că comanda Nextcloud db:add-missing-indiceseste o comandă de reparare ownCloud 10 acceptată: referința OCC actuală pentru ownCloud Server 10.15 nu o documentează. Indexurile pot face citirile corespondente mai rapide, dar fiecare index adăugat consumă spațiu de stocare și adaugă muncă la inserări, actualizări și ștergeri.

Această abordare este potrivită pentru un administrator care are o pagină ownCloud, o listă de fișiere sau o operațiune în aplicație lentă și poate accesa serverul și baza de date. Dacă întreaga instanță este lentă sau rulează pe SQLite cu mai mulți utilizatori activi, verificați configurația mai amplă a bazei de date și a implementării înainte de a trata indexurile drept cauză.

Alegeți schimbarea care corespunde dovezilor

Un index al bazei de date este o structură auxiliară care ajută baza de date să localizeze rânduri fără a scana un întreg tabel. ownCloud și aplicațiile sale definesc tabele, coloane și indexuri ca parte a schemei lor. Actualizările nucleului și ale aplicațiilor pot include migrări de schemă care creează sau ajustează acești indexuri. Prin urmare, menținerea schemei aplicației la zi este cel mai sigur prim pas.

Folosește următoarele distincții înainte de a schimba ceva:

• Avertisment administrator sau problemă cunoscută de actualizare: rulați procedura normală de actualizare ownCloud și examinați rezultatul acesteia. Migrările de actualizare sunt calea acceptată pentru modificările de schemă furnizate de ownCloud sau de o aplicație.
• O interogare lentă cunoscută cu un plan de execuție ineficient: rugați un administrator de baze de date să inspecteze interogarea și planul. Un index direcționat ar putea fi de ajutor, dar coloanele și ordinea propuse trebuie să corespundă interogării și definiției tabelului.
• Încărcări lente, blocări sau conflicte extinse: investigați tranzacțiile, latența stocării, capacitatea bazei de date și blocarea fișierelor. Aceste simptome nu dovedesc în sine lipsa unui index.
• Instalare SQLite mică care devine multi-utilizator: luați în considerare migrarea către MySQL/MariaDB sau PostgreSQL. ownCloud descrie SQLite ca fiind potrivit pentru testare și sarcini de lucru mici cu un singur utilizator, în timp ce implementările multi-utilizator de producție ar trebui să utilizeze o bază de date de server acceptată.

Un index nu este un comutator general de viteză. Mai mulți indexuri pot îmbunătăți căutările selectate, crescând în același timp dimensiunea bazei de date și latența la scriere. Rezultatul depinde de forma interogării, dimensiunea tabelului, distribuția datelor, motorul bazei de date și starea memoriei cache.

Pregătiți o fereastră de întreținere sigură

1. Înregistrați versiunile exacte și baza de date. Din directorul de instalare ownCloud, rulați comanda sudo -u www-data ./occ status. Notați versiunea ownCloud, versiunile aplicației instalate, tipul bazei de date și prefixul tabelului de la config/config.php. Înlocuiți comanda www-datacu contul de server web din distribuția dvs.
2. Capturați operațiunea lentă. Notați ecranul sau aplicația afectată, timpul aproximativ și dacă întârzierea se repetă. Examinați jurnalele ownCloud și diagnosticele pentru interogări lente ale bazei de date. Activați înregistrarea în jurnal a interogărilor numai conform instrucțiunilor furnizorului bazei de date, deoarece jurnalele pot conține valori SQL sensibile și pot crește rapid.
3. Faceți o copie de rezervă a bazei de date și a configurației. Folosiți o metodă de copiere de rezervă consistentă cu baza de date și confirmați că copia de rezervă este lizibilă. Documentația de backup a ownCloud folosește mysqldump --single-transactionca exemplu bazele de date compatibile cu MySQL; adaptați valorile gazdă, utilizator și bază de date la configurația dvs. Nu puneți o parolă a bazei de date direct în istoricul shell-ului sau într-o listă de procese.
4. Programați modificările în mod responsabil. O actualizare a schemei sau o construire a indexului poate utiliza I/O pe disc, CPU și blocări. Pentru o instalare aglomerată sau mare, informați utilizatorii despre fereastră și monitorizați încărcarea bazei de date. Utilizați modul de întreținere ownCloud numai atunci când procedura de actualizare sau întreținere aplicabilă îl solicită; nu îl activați ca înlocuitor pentru o copie de rezervă.

Aplicați mai întâi actualizările schemei gestionate de ownCloud

Dacă este în așteptare o actualizare a nucleului sau a aplicației ownCloud, utilizați procesul de actualizare documentat pentru metoda dvs. de instalare. Într-o instalare Linux convențională, comanda OCC este executată ca utilizator HTTP din directorul rădăcină ownCloud. Când urmați instrucțiunile de actualizare manuală, comanda este:

sudo -u www-data ./occ upgrade

Nu îl rulați împotriva unei instalări ale cărei fișiere au fost actualizate doar parțial. Mai întâi, pregătiți fișierele de lansare corespunzătoare și urmați pașii oficiali de actualizare pentru acea versiune. Pentru implementările Docker, utilizați invocarea OCC documentată a containerului, mai degrabă decât o cale gazdă care indică un mediu PHP diferit.

Citiți ieșirea completă a comenzii și jurnalele. O comandă executată cu succes ar trebui să se finalizeze fără a se raporta o migrare eșuată; aceasta nu garantează că fiecare interogare lentă este remediată. Dacă actualizarea raportează o eroare de migrare, opriți-o și investigați eroarea respectivă în loc să rulați comanda în mod repetat sau să editați manual tabelele de schemă. Consultați documentația de actualizare specifică versiunii ownCloud și administratorul aplicației atunci când este implicată o migrare a aplicației.

Referința ownCloud 10.15 OCC listează comenzile bazei de date, cum ar fi db:convert-type, db:convert-mysql-charset, și db:restore-default-row-format, dar nu listează db:add-missing-indices. Deoarece disponibilitatea comenzilor poate varia în funcție de versiune și de codul instalat, puteți inspecta propria instanță cu sudo -u www-data ./occ list dbsau sudo -u www-data ./occ help db:add-missing-indices. Dacă aceasta din urmă raportează o comandă necunoscută, nu copiați comanda unui tutorial Nextcloud în ownCloud. Verificați documentația pentru versiunea exactă de ownCloud și utilizați calea de actualizare sau migrare a aplicației acceptată.

Când este potrivit un index manual?

SQL-ul manual este o opțiune pentru administratorul bazei de date pentru o problemă de interogare verificată, nu o optimizare ownCloud de rutină. Mai întâi capturați exact interogarea lentă și rulați instrumentul de inspecție a planului motorului, cum ar fi EXPLAINpentru MySQL/MariaDB sau PostgreSQL. Confirmați dacă planul scanează un număr inutil de mare de rânduri și dacă un index existent este ignorat. Prefixul tabelului ownCloud este configurabil, așa că nu presupuneți niciodată că numele tabelelor încep cu oc_.

Înainte de a construi un index, comparați coloanele propuse cu filtrele, joncțiunile și ordinea de sortare ale interogării. Ordinea coloanelor unui index compozit este importantă; duplicarea unui index existent poate adăuga costuri fără a îmbunătăți planul. Solicitați unui administrator de baze de date să ia în considerare comportamentul versiunii bazei de date, suportul pentru construirea indexului online sau concurent, spațiul de stocare pe disc, impactul blocărilor și procedura de revenire la normal. Aceste detalii sunt specifice motorului și versiunii, deci nu există o singură instrucțiune SQL sigură pentru fiecare instalare ownCloud 10.

Nu modificați tabelele ownCloud și nu eliminați indexuri doar pentru că un nume pare redundant. Astfel de modificări pot intra în conflict cu o migrare ulterioară a nucleului sau a aplicației și pot defecta o funcție care utilizează o interogare diferită de cea inspectată. Păstrați o înregistrare scrisă a oricărei modificări manuale ale schemei și asigurați-vă că aceasta poate fi recreată după restaurare sau migrare. Preferați un patch sau o versiune de aplicație ownCloud acceptată atunci când indexul lipsă este un defect al schemei produsului.

Comparați alternativele la nivel de bază de date

Dacă planul folosește deja un index adecvat, adăugarea unui altul este puțin probabil să remedieze o întârziere cauzată în altă parte. Comparați aceste opțiuni cu blocajul observat:

• MySQL sau MariaDB: o opțiune comună pentru implementările ai căror administratori operează deja aceste motoare. Verificați memoria buffer-pool, latența discului, conexiunile și planurile de interogare lentă înainte de a modifica setările serverului.
• PostgreSQL: o alternativă acceptată pentru ownCloud 10, unde conectorul bazei de date PHP și implementarea sunt configurate corect. Planurile sale de interogare și instrumentele de întreținere a indexului diferă de MySQL, așadar, utilizați sfaturile specifice PostgreSQL.
• SQLite: ușor de utilizat pentru testare sau utilizare de către un singur utilizator, dar nu este opțiunea implicită pentru o sarcină de lucru de producție concurentă, cu mai mulți utilizatori. Reglarea indexului nu poate elimina limitele de concurență ale implementării.

Schimbarea motoarelor de baze de date este un proiect de migrare, nu o modificare rapidă a indexului. ownCloud oferă occ db:convert-typeconversii acceptate; verificați cerințele preliminare, faceți mai întâi o copie de rezervă și testați instanța convertită înainte de a direcționa utilizatorii către ea.

Verificați rezultatul și opriți-vă dacă dovezile sunt contrare

Repetați aceeași acțiune a utilizatorului în condiții comparabile și comparați durata interogării, planul de execuție, rândurile examinate, I/O-urile din baza de date și încărcarea serverului. Confirmați că pagina sau aplicația ownCloud relevantă se finalizează normal și că jurnalele nu arată erori de bază de date sau de migrare. Un rezultat mai rapid la o singură solicitare nu dovedește o îmbunătățire generală; comparați mai multe solicitări reprezentative și luați în considerare memoriile cache la cald.

Dacă aceeași interogare rămâne lentă în timp ce utilizează un index adecvat, investigați blocările, spațiul de stocare, latența rețelei, workerii PHP și limitele resurselor bazei de date. Dacă planul de interogare sau structura tabelului este neclare, opriți-vă înainte de a emite DDL manual și solicitați unui administrator de baze de date sau unei persoane de contact pentru asistență ownCloud să o revizuiască. Rezultatul fiabil este o schemă aliniată cu versiunea ownCloud instalată și interogările măsurate, fără modificări ale indexului neurmărite.

Referințe oficiale

• Referință comenzi OCC pentru ownCloud Server 10.15
• Procedura de actualizare manuală pentru ownCloud Server 10.15
• Ghid de conversie a bazei de date ownCloud Server 10.15
• Documentație de backup pentru ownCloud Server 10.15
• Documentație de administrare ownCloud Server 10.15