Project

General

Profile

Actions

Bug #1205

closed

MongoDB - výkonnostní problémy

Added by Radomír Orkáč over 10 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
High
Category:
Development - Core
Target version:
Start date:
09/06/2013
Due date:
% Done:

0%

Estimated time:
To be discussed:

Description

Musim overit, co se stalo po nahrani dat do testovaci databaze.
Co zpusobuje vykonnostni problemy.
Cili co je pricinou tak dramaticke zmeny ve vykonnosti.

# time perl mongodb_aggr.pl
real    0m4.190s
user    0m0.488s
sys     0m0.036s

# time perl mongodb_aggr.pl
real    3m48.255s
user    0m0.484s
sys     0m0.076s

Related issues

Related to Mentat - Bug #1009: Zobrazení hlavní stránky trvá hrozně dlouhoClosedRadomír Orkáč05/30/2013

Actions
Related to Mentat - Bug #1450: Poměrně malé dotazy trvají neúměrně dlouhoClosedRadomír Orkáč03/11/2014

Actions
Actions #1

Updated by Pavel Kácha over 10 years ago

  • Target version set to 0.6
Actions #2

Updated by Pavel Kácha over 10 years ago

db.serverStatus( { workingSet: 1 } )

Možná porovnat návrh workingsetu od Monga před zlomem výkonu a po zlomu.

http://docs.mongodb.org/manual/reference/server-status/
http://docs.mongodb.org/manual/reference/method/db.serverStatus/

Actions #3

Updated by Pavel Kácha over 10 years ago

  • Priority changed from Normal to High
Actions #4

Updated by Pavel Kácha over 10 years ago

  • Priority changed from High to Low
Actions #5

Updated by Pavel Kácha over 10 years ago

  • Subject changed from mongodb - vykonnostni problemy po importu to mongodb - vykonnostni problemy
Actions #6

Updated by Pavel Kácha over 10 years ago

Pro dashboard (#1009) se pravděpodobně používá jen jeden z indexů, je možné, že bude potřeba vytvořit sdružené indexy.

Actions #7

Updated by Radomír Orkáč about 10 years ago

Jen jsem se dostal k otestovani "indexu" u aggregate.

Mongodb 2.6 bude mit explain() i pro aggregate:
http://docs.mongodb.org/master/reference/method/db.collection.aggregate/#db.collection.aggregate

db.alerts.aggregate([{  
    '$match': { 'ts_u': { '$lte': 1394406000, '$gte': 1394319600 } }  
},  
{  
    '$project': {  
                    'source': '$Alert.Analyzer.@analyzerid',  
                    'timegr': {  
                                  '$divide': [  
                                                 {  
                                                   '$subtract': [  
                                                                    { '$subtract': [ '$ts_u', 1394319600 ]},
                                                                    { '$mod': [ { '$subtract': [ '$ts_u', 1394319600 ] }, 3600 ]}
                                                                  ]
                                                 }, 3600 ]
                                },
                    'time': '$ts_u', 'name': '$Alert.Analyzer.@name'
                  }
},
{
    '$group': {
                  '_id': {
                             'source': { '$concat': [ '$source', '/', '$name' ]},
                             'timegr': '$timegr'
                           },
                  'sum': { '$sum': 1 }
                }
}]);

Match ale index vyuziva:

db.alerts.find({ 'ts_u': { '$lte': 1394406000, '$gte': 1394319600 }}).explain();
{
        "cursor" : "BtreeCursor ts_u_1",
        "isMultiKey" : false,
        "n" : 191459,
        "nscannedObjects" : 191459,
        "nscanned" : 191459,
        "nscannedObjectsAllPlans" : 191459,
        "nscannedAllPlans" : 191459,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 0,
        "nChunkSkips" : 0,
        "millis" : 252,
        "indexBounds" : {
                "ts_u" : [
                        [
                                1394319600,
                                1394406000
                        ]
                ]
        },
        "server" : "mentat:27017" 
}

Actions #8

Updated by Pavel Kácha almost 10 years ago

  • Priority changed from Low to High

Zkusit podobný přístup jako u Alerts/Detector - říci si běžným selectem u Detectoru, Analyzeru a Classification o seznam všech a pak se ptát find().count() na konkrétní počty (byť hodněkrát). Je možné, že několik set dotazů, u kterých se ale použije index a nebude se sahat do dat, bude výrazně rychlejších, než agregace, která použije index jen na úvodní select a pak iteruje přes všechny dokumenty.

Actions #9

Updated by Jan Mach almost 10 years ago

  • Subject changed from mongodb - vykonnostni problemy to MongoDB - výkonnostní problémy

V MongoDB driverech (source:lib/Mentat/Storage/Mongo.pm, source:lib/Mentat/Message/Storage/Mongo.pm) jsem naimplementoval novou metodu iterativního procházení výsledkem (commit:6b41454c), aby bylo možné dělat agregace nad neomezeným počtem položek v databázi v paměti programu. Způsob použití je popsán v POD dokumentaci jednotlivých modulů, více také viz. úkol #1454, odrážka 2.

Actions #10

Updated by Radomír Orkáč almost 10 years ago

  • Status changed from New to In Progress

Pavel Kácha wrote:

Zkusit podobný přístup jako u Alerts/Detector - říci si běžným selectem u Detectoru, Analyzeru a Classification o seznam všech a pak se ptát find().count() na konkrétní počty (byť hodněkrát). Je možné, že několik set dotazů, u kterých se ale použije index a nebude se sahat do dat, bude výrazně rychlejších, než agregace, která použije index jen na úvodní select a pak iteruje přes všechny dokumenty.

Tohle se bohuzel ukazalo jako spatna cesta.. nepomohla:(

Distinct nad (napr.) classification (dokonce omezenou casovym rozsahem).
Kazdou (napr.) classification zvlast jsem pomoci find vyhledaval a pocitat (mnoho dotazu) pocty (s vyuzitim granularity).

Na VSB se jednalo o 3s zrychleni (12s versus 9s), ale na mentat-dev (kontroloval jsem 5x indexy, jsou skutecne stejne) to bylo o temer 40s pomalejsi (24s versus 61s). Duvod neznam. find().explain() ukazoval stejne pouzivani indexu na VSB i mentat-dev a podminky byly stejne.

24.43
---
Remote login => 186
Spam => 9
SMB exploitation attempt => 302
SQL query attack attempt => 46
URL attack attempt => 111
Webattack => 147
Other => 138
Botnet Command and Control => 28
Botnet Drone => 155
Malware => 2
Connection attempt => 2274881
Bruteforce => 862
Probe => 100414
Portscan => 359266
Open DNS Resolver => 1807
---
61.44
Remote login => 186
Spam => 9
SMB exploitation attempt => 302
URL attack attempt => 111
SQL query attack attempt => 46
Webattack => 147
Other => 138
Botnet Command and Control => 28
Botnet Drone => 155
Malware => 2
Connection attempt => 2274881
Probe => 100414
Portscan => 359266
Bruteforce => 862
Open DNS Resolver => 1807

Jak jsem navrhnul Pavlovi, vyzkousim na mentat.vsb.cz (pokud muzu na mentat-dev, budu radsi) nove mongodb 2.6.
Do pondelniho seminare.
Souhlas?

Actions #11

Updated by Pavel Kácha almost 10 years ago

Jak jsem navrhnul Pavlovi, vyzkousim na mentat.vsb.cz (pokud muzu na mentat-dev, budu radsi) nove mongodb 2.6.
Do pondelniho seminare.
Souhlas?

Jsem pro. Zkus, co stihneš. Mek nemá nic proti tomu to otestovat na mentat-dev. ALE - prioritu má hlavně, aby současný kód co nejlépe chodil na semináři - je dost pravděpodobné, že to bude chtít leckdo vidět, případně Andrea někomu ukázat.

Radomír Orkáč wrote:

Pavel Kácha wrote:
Na VSB se jednalo o 3s zrychleni (12s versus 9s), ale na mentat-dev (kontroloval jsem 5x indexy, jsou skutecne stejne) to bylo o temer 40s pomalejsi (24s versus 61s). Duvod neznam. find().explain() ukazoval stejne pouzivani indexu na VSB i mentat-dev a podminky byly stejne.

Tak to je pech. Mám ještě jeden nápad, ve volném čase připíšu, ale má taky svoje komplikace.

Actions #12

Updated by Pavel Kácha almost 10 years ago

Radomír Orkáč wrote:

Na VSB se jednalo o 3s zrychleni (12s versus 9s), ale na mentat-dev (kontroloval jsem 5x indexy, jsou skutecne stejne) to bylo o temer 40s pomalejsi (24s versus 61s). Duvod neznam. find().explain() ukazoval stejne pouzivani indexu na VSB i mentat-dev a podminky byly stejne.

Ještě - pokud jsi to neudělal, zkus to prosímtě porovnat BEZ úvodního generování seznamu, resp. ono je potřeba ho udělat, ale nepočítej ho do času, jen ty countovací dotazy. Seznamy se dají předgenerovat.

Actions #13

Updated by Radomír Orkáč almost 10 years ago

To jsem zkousel, ale zkusim to jeste ted pod mentat-dev

Vysledky z VSB jsem mel v poznamkach:

Bez indexu:
Stavajici agregace: 10.32
Ziskani seznamu clasifikaci za dane obdobi: 4.04
Dotazy na jednotlive klasifikace: 46.36

S indexem:
db.alerts.ensureIndex( { "ts_u": 1, "Alert.Classification.@text": 1 } )
Stavajici agregace: 12.10
Ziskani seznamu clasifikaci za dane obdobi: 2.12
Dotazy na jednotlive klasifikace: 6.96

Actions #14

Updated by Radomír Orkáč almost 10 years ago

Stavajici agregace: 25.14
Distinct klasifikaci (s casovym omezenim): 5.81
Dotazy s granularitou a jednotlivou klasifikaci: 58.82

mentat-dev:

perl mongodb_test2.pl 
25.14
5.81
58.82
---
Remote login => 186
Spam => 9
SMB exploitation attempt => 302
SQL query attack attempt => 46
URL attack attempt => 111
Webattack => 147
Other => 138
Botnet Command and Control => 28
Botnet Drone => 155
Malware => 2
Connection attempt => 2274881
Bruteforce => 862
Probe => 100414
Portscan => 359266
Open DNS Resolver => 1807
---
Remote login => 186
Spam => 9
SMB exploitation attempt => 302
URL attack attempt => 111
SQL query attack attempt => 46
Webattack => 147
Other => 138
Botnet Command and Control => 28
Botnet Drone => 155
Malware => 2
Connection attempt => 2274881
Probe => 100414
Portscan => 359266
Bruteforce => 862
Open DNS Resolver => 1807

Actions #15

Updated by Pavel Kácha almost 10 years ago

Actions #16

Updated by Radomír Orkáč almost 10 years ago

Pavel Kácha wrote:

db.alerts.getIndexes()
[
        {
                "v" : 1,
                "key" : {
                        "_id" : 1
                },
                "name" : "_id_",
                "ns" : "test.alerts" 
        },
        {
                "v" : 1,
                "key" : {
                        "Alert.Source.Node.Address.ipv4.min" : 1,
                        "Alert.Source.Node.Address.ipv4.max" : 1
                },
                "name" : "Alert.Source.Node.Address.ipv4.min_1_Alert.Source.Node.Address.ipv4.max_1",
                "ns" : "test.alerts" 
        },
        {
                "v" : 1,
                "key" : {
                        "Alert.Source.Node.Address.ipv4.max" : 1,
                        "Alert.Source.Node.Address.ipv4.min" : 1
                },
                "name" : "Alert.Source.Node.Address.ipv4.max_1_Alert.Source.Node.Address.ipv4.min_1",
                "ns" : "test.alerts" 
        }
]
Actions #17

Updated by Pavel Kácha almost 10 years ago

  • mluvili jsme o prohození pořadí položek ve složeném indexu, kvůli kardinalitě - zkus ještě jednou a pozor na skutečné pořadí (hash/ixhash) a jména indexů
Actions #19

Updated by Radomír Orkáč almost 10 years ago

mentat-dev

Jedna se nejprve o volani agregacniho dotazu, tak jak ho pouzivame v dashboard (cas "Agregace").
Nasledne je agregacni dotaz predelan do nacteni klasificaci pres distinct za urcite obdobi (cas "Distinct") a mnoho findu (cas "Granularitni findy").

Rychlost je uctyhodna, viz druhy zaznam "code". Pokud bychom meli klasifikace predem, mnoho granularitnich findu probehlo za 2s.
Agregacni casy zustaly stejne.

Tie::IxHash->new('ts_u' => 1, 'Alert.Classification.@text' => 1);

Agregace: 50.96
Distinct: 27.14
Granularitni findy: 430.78
Tie::IxHash->new('Alert.Classification.@text' => 1, 'ts_u' => -1);

Agregace: 50.79
Distinct: 27.11
Granularitni findy: 2.13
---
Scanners => 6
(D)DoS => 3
Spam => 1
SMB exploitation attempt => 1813
SQL query attack attempt => 149
Other => 588
Webattack => 381
Scan QOTD => 86
Malware => 1
Scan CHARGEN => 90
Portscan => 1006423
Probe => 278060
Open DNS Resolver => 1951
Open DNS resolver => 19
Remote login => 926
URL attack attempt => 376
Scan SSDP => 1974
Botnet Drone => 269
Botnet Command and Control => 86
Bruteforce => 1452
EPMAPPER exploitation attempt => 1
Connection attempt => 5134616
---
Scanners => 6
(D)DoS => 3
Spam => 1
SMB exploitation attempt => 1813
SQL query attack attempt => 149
Other => 588
Webattack => 381
Scan QOTD => 86
Malware => 1
Scan CHARGEN => 90
Portscan => 1006423
Probe => 278060
Open DNS Resolver => 1951
Open DNS resolver => 19
Remote login => 926
URL attack attempt => 376
Scan SSDP => 1974
Botnet Drone => 269
Botnet Command and Control => 86
EPMAPPER exploitation attempt => 1
Bruteforce => 1452
Connection attempt => 5134616
Actions #20

Updated by Radomír Orkáč almost 10 years ago

Ostry mentat, mnoho granularitnich findu je opravdu rychlych.
Pokud budeme mit predpripraven distinct, je to otazkou jednotek vterin.

Agregace: 178.90
Distinct: 66.47
Granularitni findy: 3.35
---
Scanners => 8
Spam => 13
(D)DoS => 27
SMB exploitation attempt => 2263
SQL query attack attempt => 221
Other => 787
Webattack => 587
Bots => 4
Scan QOTD => 86
Malware => 4
Scan CHARGEN => 90
Probe => 427449
Portscan => 1521862
Open DNS Resolver => 4273
Open DNS resolver => 20
Remote login => 1240
Proxy server => 2
URL attack attempt => 534
Scan SSDP => 1974
Botnet Command and Control => 130
Botnet Drone => 487
EPMAPPER exploitation attempt => 1
Bruteforce => 2746
Connection attempt => 8379582
Malware URL => 2
---
Scanners => 8
(D)DoS => 27
Spam => 13
SMB exploitation attempt => 2263
SQL query attack attempt => 221
Webattack => 587
Other => 787
Scan QOTD => 86
Bots => 4
Malware => 4
Scan CHARGEN => 90
Probe => 427449
Portscan => 1521862
Open DNS Resolver => 4273
Open DNS resolver => 20
Remote login => 1240
Proxy server => 2
URL attack attempt => 534
Scan SSDP => 1974
Botnet Drone => 487
Botnet Command and Control => 130
EPMAPPER exploitation attempt => 1
Bruteforce => 2746
Connection attempt => 8379582
Malware URL => 2
Actions #21

Updated by Pavel Kácha almost 10 years ago

Co tedy bylo příčinou? To, že se používal hash bez ohledu na pořadí?

Takže je teď ještě otázka, zda to něco udělá s klasickými dotazy (Alerts).

K zamyšlení (na schůzku):
  • jak generovat seznamy k distinctu
    • pravidelný cron? (nemusí být aktuální od posledního volání)
    • pravidelný cron za poslední den s mergováním? (pokud by dotaz přes celou db vyléval cache pro ostatní dotazy)
    • nějaký procesor ve frontě zpracování zprávy, který bude online přidávat nové položky? (stojí to za tu práci?)
  • využít cache?
Actions #22

Updated by Pavel Kácha almost 10 years ago

A ještě mě napadlo - pokud bychom generovali distinct seznamy jednou za den, jak dlouho trvá distinct dotaz (pokud možno s indexem ) za posledních 24 hodin?

Actions #23

Updated by Radomír Orkáč almost 10 years ago

Na mentat (ostrem) to trva za 24h 2.97s.
Pozor, mereno jen u klasifikaci. Muze se to lisit.. .

Epoch timestamp: 1398082960
Human time (your time zone): Po 21. duben 2014, 14:22:40 CEST

my $result = $DB->run_command([
    "distinct"  => "alerts",
    "key"       => 'Alert.Classification.@text',
    'query' => {'ts_u' => {'$gte' => 1398082960}}
]);
# perl mongodb_distinct.pl 
2.97

$VAR1 = {
          'ok' => '1',
          'stats' => {
                     'nscanned' => 376885,
                     'n' => 376885,
                     'cursor' => 'BtreeCursor ts_u_1',
                     'nscannedObjects' => 376885,
                     'timems' => 2965
                   },
          'values' => [
                      'Connection attempt',
                      'Portscan',
                      'Remote login',
                      'Probe',
                      'Bruteforce',
                      'Botnet Command and Control',
                      'URL attack attempt',
                      'Webattack',
                      'SQL query attack attempt',
                      'Open DNS Resolver',
                      'SMB exploitation attempt',
                      'Botnet Drone',
                      'Other',
                      'Scan SSDP',
                      'Scan CHARGEN',
                      'Scan QOTD',
                      'Open DNS resolver',
                      'Spam'
                    ]
        };
Actions #24

Updated by Pavel Kácha almost 10 years ago

  • vyzkoušet výkonově i přes IP adresy Source a Destination (tam není teoreticky omezený počet a může to skončit na milionu dotazů do db) a přes ostatní Classification, Analyzer, Detector.
  • bude pak zřejmě potřeba se zamyslet nad předcachováním (možná nějakým způsobem do db a ne do cache) seznamů IP, resp. mechanismu zjištění seznamu IP adres, které se vyskytly pro určitou síť v určitém intervalu (abychom pro ně mohli položit dotazy)
  • změnit mechanismus generování názvu do cache - nehashovat, ať je vidět v názvu souboru, co je to za cache

Pozn: Bylo by dobré ten testovací skript psát zase tak, aby se velká část stejného kódu používala pro generování všech, a tak, abys do ostrého kódu musel minimum přepisovat.

Actions #25

Updated by Jan Mach about 7 years ago

  • Status changed from In Progress to Closed

Již neaktuální, úklid v úkolech, zavírám.

Actions

Also available in: Atom PDF