Roundcube e-mail keresés lassú

Web, mail, IRC, IM, hálózatok

Üdv Mindenkinek!

Adott egy levelező szerver roundcube-al, minden nagyszerűen működik, csak egy probléma van az hogy a roundcube a levelek között 1-4 percig is keres egy tételt. A fiókban 6000 levél van ami szerintem nem számít soknak. Ha megadok egy random keresést mondjuk egy e-mail címre akkor azzal nagyon sokáig elszöszmötöl.

Már nagyon sok helyen utána olvastam és meg is tettem a megfelelő lépéseket (roundcube cache mysql, php memcache ) de számottevő gyorsulást nem értem el.

Van esetleg valami ötletetek hogyan lehetne felgyorsítani az e-mailok közötti keresést?

Előre is köszönöm.

  • 2665 megtekintés

( gedez | 2016. 05. 28., szo – 20:39 )

IO probléma szerintem... Nekem úgy tűnik a számokból, hogy 1db HDD szolgálja ki, és azért tart ennyi ideig.

IO teljesítmény alatt az adott időegység (1 sec) alatt elvégezhető IO műveletek számát értjük. (IOPS)
Ennek semmi köze nincs a szekvenciális írási és olvasási sebességhez.

Merevlemezes tárolók esetén az IOPS teljesítményt leginkább a diszkek fordulatszáma, a diszkek (komponensek) darabszáma, és az alkalmazott RAID szint határozza meg. (Meg még egy csomó minden más is, pl. blokkméret, párhuzamos szálak száma, cache, ... de az előbbiek a fontosabb tényezők)

Néhány példa:
a.) 1 darab 7200rpm konzumer SATA diszk: kb. 70-80 IOPS
b.) 1 darab 15000rpm enterprise SAS diszk: kb. 140-160 IOPS
c.) 8 darab SAS diszkből álló RAID5 tömb: kb. 600-800 IOPS
d.) 1 darab SSD: kb. 8000-10000 IOPS

Tehát, ha a keresésedhez mondjuk 10000 IO művelet szükséges, akkor az a.) esetében kb. 2,5 percig fog tartani a keresés, a c.) esetben kb. 15 másodpercig, a d.) esetben pedig kb. 1 másodpercig.

Az alábbi teszttel
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=8 --runtime=240 --group_reporting

Ezek az értékek születtek:

randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
...
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
2.0.8
Starting 8 processes
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
randwrite: Laying out IO file(s) (1 file(s) / 512MB)
Jobs: 8 (f=8): [wwwwwwww] [54.6% done] [0K/6101K /s] [0 /1525 iops] [eta 03m:20s]
randwrite: (groupid=0, jobs=8): err= 0: pid=777
write: io=2317.1MB, bw=9887.2KB/s, iops=2471 , runt=240071msec
slat (usec): min=6 , max=5370.6K, avg=3226.14, stdev=19904.18
clat (usec): min=1 , max=20014 , avg= 3.38, stdev=53.22
lat (usec): min=8 , max=5370.6K, avg=3231.39, stdev=19904.72
clat percentiles (usec):
| 1.00th=[ 1], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 2],
| 30.00th=[ 2], 40.00th=[ 2], 50.00th=[ 3], 60.00th=[ 3],
| 70.00th=[ 3], 80.00th=[ 4], 90.00th=[ 5], 95.00th=[ 6],
| 99.00th=[ 8], 99.50th=[ 9], 99.90th=[ 20], 99.95th=[ 30],
| 99.99th=[ 294]
bw (KB/s) : min= 0, max=103185, per=12.89%, avg=1274.56, stdev=4442.39
lat (usec) : 2=2.76%, 4=69.68%, 10=27.16%, 20=0.29%, 50=0.07%
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
cpu : usr=0.19%, sys=0.65%, ctx=74075, majf=1, minf=187
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=593402/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
WRITE: io=2317.1MB, aggrb=9887KB/s, minb=9887KB/s, maxb=9887KB/s, mint=240071msec, maxt=240071msec

Disk stats (read/write):
xvda1: ios=901/500795, merge=72/103181, ticks=37112/15211320, in_queue=15256388, util=98.43%

Ez így azt mondja, hogy 1525 IOPS, de mindig nagy élmény az almát a körtével összehasonlítani, így kérlek, futtasd le az én fenti fio.conf-ommal is. (Az általad használt paraméterekkel az én bombabiztosan 16400 IOPS-os storage-emre azt mondja, hogy 48000 IOPS, ami hülyeség.)

A te fio konfigod szerint:

random: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=2
...
random: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=2
2.0.8
Starting 4 processes
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
Jobs: 1 (f=1): [__r_] [100.0% done] [756K/0K /s] [189 /0 iops] [eta 00m:00s]
random: (groupid=0, jobs=4): err= 0: pid=1421
read : io=4096.0MB, bw=1592.3KB/s, iops=398 , runt=2634239msec
clat (usec): min=69 , max=827610 , avg=9849.29, stdev=9052.46
lat (usec): min=70 , max=827611 , avg=9850.86, stdev=9052.47
clat percentiles (usec):
| 1.00th=[ 247], 5.00th=[ 868], 10.00th=[ 2544], 20.00th=[ 3920],
| 30.00th=[ 5216], 40.00th=[ 6496], 50.00th=[ 7712], 60.00th=[ 8896],
| 70.00th=[10048], 80.00th=[14272], 90.00th=[20608], 95.00th=[27008],
| 99.00th=[38144], 99.50th=[42752], 99.90th=[110080], 99.95th=[130560],
| 99.99th=[152576]
bw (KB/s) : min= 10, max= 1046, per=25.50%, avg=406.01, stdev=78.47
lat (usec) : 100=0.02%, 250=1.02%, 500=3.52%, 750=0.39%, 1000=0.10%
lat (msec) : 2=1.78%, 4=13.78%, 10=48.79%, 20=19.97%, 50=10.38%
lat (msec) : 100=0.14%, 250=0.12%, 1000=0.01%
cpu : usr=0.07%, sys=0.65%, ctx=1054004, majf=2, minf=99
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=1048576/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
READ: io=4096.0MB, aggrb=1592KB/s, minb=1592KB/s, maxb=1592KB/s, mint=2634239msec, maxt=2634239msec

Disk stats (read/write):
xvda1: ios=1058466/3051, merge=97/4260, ticks=10448780/262175964, in_queue=272624852, util=100.00%

( Tassadar v | 2016. 05. 28., szo – 21:52 )

Kikapcsolt rc cache-l változik?

Jó lenne ismerni a roundcube belsejét, hogy mit futtat és hol. Ha saját mysql-ben vannak a levelek, akkor annak táblaformátuma és a benne lévő adatok alapján lehetne megnézni, hogy mi a lassú:
- alap SELECT is lassú? Nincs index?
- sok SELECT fut le, talán a szövegtörzsben is keres az email címekre fulltext nélkül?

https://forums.cpanel.net/threads/roundcube-very-slow.396151/ -ben leírtam szerint lassúnak tekinthetjük a 0.2mp-es lekérdezéseket. 5-10mp már nagyon sok.

( sj | 2016. 05. 29., v – 01:05 )

az imap szerver valaszol lassan. Mondjuk nem is arra lettek kitalalva, hogy keress a levelek kozott, arra sokkal megfelelobb egy email archivalo megoldas, ami foallasban vegez indexelest, ill. keresest...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

nincs ra kesz megoldas. Annal is inkabb nem, mert az email archivalas (definicio szerint) egy masik gepen fut, igy az rc-be (=random webmail-be) bedrotozas* nem feltetlen trivialis. De egy megadott mailboxban valo sima keresesre eleg lehet a lentebb emlitett dovecot extra.

*: foleg ha egy zart forrasu, kotott megoldasod van

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

ja, ha a 'kb' fogalmat eleg lazara veszed, akkor valoban. Ellenkezo esetben:

kerdezo: az rc k lassan keres
en: az imap szerver valaszol lassan. Btw. az imap szerverek nem arra lettek kitalalva, hogy keress a levelekben. Erre a funkciora sokkal jobb egy email archivalo megoldas, ami foallasban vegzi ezt a feature-t (meg meg sok mast is)

keef: hogy lehet ezt rc-be drotozni?
en: nice try (valo igaz, nem vittem vegig azt a fonalat, hogy megis mi a banatert kene ezt {pont} az rc-be drotozni, meg hogy miert az imap szervert akarja a kerdezo tuningolni, ami sose fog ugy teljesiteni, mint egy erre kihegyezett cucc)

Tehat ha xy levelekben akar keresni, akkor imho nem "teljesen irrelevans" egy olyan megoldasra felhivni a figyelmet, ami erre van kihegyezve...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

csak van sok szerver-implementáció, amelyeket igen gyér keresési lehetőségekkel vérteztek fel.

en mashogy fogalmaztam meg :-)

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

lattam, azonban az csak utolag derult ki, hogy a topiknyitonal is dovecot van. Btw. ez csak egyetlen imap implementacio, a tobbire meg allhat, amit irtam...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szerencsére az informatika az a tudomány, ahol különféle erőforrások hatékony felhasználásával akár nagyságrendeket lehet javítani a teljesítményen, ilyen például az, hogy nem full table scan alapú a full text search és akkor nem az I/O lesz a szűk keresztmetszet... persze lehet puszta erőből is megoldani a problémákat, az is egy út.

Tehát akkor jelen esetben nem az a gond, hogy mindössze 189 IOPS-ot tud a diszk, hanem pusztán beállításokkal el lehet érni, hogy a kérdező keresése ne 4 perc alatt fusson le, hanem mindössze pár másodperc alatt?
Mondd már el, hogy hogyan, köszi.
(A matematika és a tények makacs dolgok.. Kétlem, hogy amíg az I/O teljesítményen nem javítasz, addig bármi beállítással elérsz 1-2% -nál jobb eredményt... a meg ugye lepkefing, nem erre irányult a kérdés, nem optimalizálni kell 1-2%-ot, hanem a 4 perces keresési időt redukálni "normáli", pár másodpercre......... Ennyi IOPS-sal ezt nem fog menni, ez teljesen nyílván való. Ha szignifikánsan kevés az I/O erőforráss, akkor lehet az informatika bármilyen tudomány, nincs mit ezen a nevetséges 189 IOPS-on hatékonyabban felhasználni. Fából nem lesz vaskarika, akármilyen okos is vagy.
Továbbra is tartom, hogy :"ti hogy tudtok a semmi porogni meg mindig, amikor mar reg kiderult hogy tetu lassu a lemez a gepben es emiatt ilyen lassu...?!")

"Tehát akkor jelen esetben nem az a gond, hogy mindössze 189 IOPS-ot tud a diszk, hanem pusztán beállításokkal el lehet érni, hogy a kérdező keresése ne 4 perc alatt fusson le, hanem mindössze pár másodperc alatt?"

Igen, egy megfelelő FTS plugin nagyságrendeket javít az időn, lásd a Dovecot saját mérését:

1,4 GB mbox with 368000 messages: SEARCH BODY asdfgh
Without Squat: 2 min 35 sec CPU, process RSS size 24 MB
Initial Squat build: 6 min 36 sec CPU, process RSS size peaks at 800 MB, drops to 96 MB at end.
Subsequent searches: 0.10 sec CPU, 1.18 sec real with cold cache, process RSS size 2 MB.
Most of the time was spent verifying Squat results. Searching for a 1..4 letter word gives results in 0.00 CPU secs and 0.80 real secs with cold cache.

Voilà, a keresés percekről lement másodperc töredékére... és még nem is egy Solr volt alátéve a kevés adat miatt, hanem a Dovecot saját FTS megoldása, amely azért egy kicsit erőforrás zabáló. Persze lehet sok pénzért storage cserét is eszközölni, de érdemes azért előtte kicsit gondolkodni, mérni és konfigurációt módosítani...

Szóval?

( Fisher v | 2016. 05. 29., v – 01:43 )

Nincs véletlenül bekapcsolva hogy a body-ban is keressen? Akkor nekem 30k levélnél már erősen megcsigul. Ha bárhol máshol (from, tú, miegyéb) keresek, akkor a 75k levél is megvan 2-3 másodperc alatt. Több levelem nincs egy folderben :D

( Madman | 2016. 05. 29., v – 13:16 )

nekem RC ugy ahogy van kibirhatatlanul lassu, nem csak keresesnel, siman belepes utan az inbox betoltese is kinszenvedes, eltart vagy 10 masodpercig csak az elso oldalra varni, tuti h nem kulso problema mivel ugyanazon a gepen futo ugyanazt az imap servert hasznalo masik webmail (atmail vagy akar sqmail) 1 sec alatt behozza az egeszet...

nekem is volt ilyen, a nevfeloldassal volt baja, atirtam az imapszerver beallitast ( $config['default_host'] ) ipcimre, megy mint a villam.

* ha kiprobalod, es mar van mogotte adatbazis, akkor az users tablaban a mail_host mezot updatelni kell, mert az userek nem fogjak latni a kontaktokat es egyeb beallitasaik is latszolag eltunnek.

10 másodperc az nekem túl soknak tűnik. Mekkora terhelés van a vason? Milyen lemezek pörögnek alatta? Be van állítva valamilyen PHP opcode cache? Nekem egy SAS-os lemezekből álló RAID5 tömbbön levő VM-ben futó 12.04-es Ubuntun 3 másodperc telik el a Login gombra kattintástól a postafiók tartalmának megjelenítéséig úgy, hogy azon a vason más VM-ek is futnak.

mar par eve nem probaltam, anno a regi gepen mindig 0 kozeli load volt, sima raid1-es sata diskek voltak alatta, es volt apc meg (talan) 5.3-as php (azt hiszem talan az meg squeeze volt, bar mar egy ideje nincs meg ugyhogy pontosan nem emlekszem), azota nem probaltam amiota mar vannak ssdk meg ujabb php, de ez mind nemszamit osszehasonlitasban, mert mint mondtam ugyanazon a gepen futo, ugyanazt az imap szervert hasznalo squirrel poccre behozta gyakorlatilag azonnal (atmail free is). es azok is ugyanazt a phpt hasznaltak es uagyanzt a disket.
A postafiokban egyebkent kb 12-13k level volt akkoriban osszesen, es valoszinuleg nem 10 mp volt, de 6-7 tuti. Mig a masik kett kb 1-2 sec es megcsinalta ugyanazt

( Marxs v | 2016. 05. 29., v – 16:58 )

Szervusz!

Elsősorban én is a diszk felől közelíteném a problémát, illetve fontos lenne tudni, hogy az imapot ki adja mert például a dovecot jóval gyorsabban keres mint a courier.

M.

( pepo v | 2016. 06. 12., v – 17:14 )

Ha jól láttam, senki nem írt arról, hogy kíváncsiságból pl. egy Thunderbird által kezdeményezett keresés is ilyen lassú-e?