Mentat

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/

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

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" 
}

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.

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.

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

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

• 2.6 (viz #1450)
• měla by mít explain u agregace
• údajně změny limitů agregace
• http://docs.mongodb.org/manual/release-notes/2.6/#aggregation-enhancements

Pavel Kácha wrote:

• 2.6 (viz #1450)
• měla by mít explain u agregace
• údajně změny limitů agregace
• http://docs.mongodb.org/manual/release-notes/2.6/#aggregation-enhancements

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" 
        }
]

• 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ů

Max 40 indexes per collection:
http://www.slideshare.net/mongodb/indexing-with-mongodb

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

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

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).

• 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?

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?

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'
                    ]
        };

• 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.