irrdb-cli.update-prefix-db takes very long on AS-HURRICANE #284
Comments
|
The first comment I'll make on this is that it doesn't really matter from a production point of view how long this takes. It's intended as a cron script that's run in the back ground. It's also transaction safe at the database level so route server generation does not need to be tied to running this. They can safely overlap with zero consequences. For reference, documentation is at: https://github.com/inex/IXP-Manager/wiki/IRRDB-Prefixes I'm just doing a timed run now on INEX's version to compare. Will come back shortly. |
|
@kieber - could you run it again with surrounding |
|
It may be safe transaction-wise, but: If you add a new peer to IXPM and then run route server config generation before running irrdb-cli.update-{asn,prefix}-db, the new peer generates errors. Thus running RS config generation before irrdb-cli.update-{asn,prefix}-db is also kinda operationally useless, running it considerably later doesn't give an advantage either, and running it more than once after irrdb-cli.update-{asn,prefix}-db doesn't produce any different results than the first run. That said, I'd prefer doing a full run of both, irrdb-cli.update-{asn,prefix}-db followed by RS config generation before starting another cycle, just to spare me from the cron mails. The other output comes tomorrow morning. :) |
|
So, here is an output of date ; echo "Running irrdb-cli.update-asn-db:" Tue 20 Dec 03:00:01 CET 2016 Running irrdb-cli.update-asn-db: Tue 20 Dec 03:03:06 CET 2016 Running irrdb-cli.update-prefix-db: Tue 20 Dec 05:32:42 CET 2016 |
Not sure what the situation was on v3 but certainly on v4, config gen won't produce an error in this situation. The member will just be reject all until the data is populated. |
So the issue here was PHP's general well-known efficiency with arrays (internal hash table) and how we were using them (n x linear traversal's where n is the number of prefixes). It didn't come up for us previously as we did not have a route server member with this scale of prefixes. In the above commit (6b5a0aa) I have replaced arrays with a new PHP 7 data structure The result is that for the same data set (AS-HURRICANE), processing time has gone from ~8570 secs to ~3.5 secs. |
|
that was a github comment delivered with no small level of satisfaction. |
|
Note that to make use of this, you'll need the php-ds extension. Ubuntu mainline are slow to the party here: https://packages.ubuntu.com/search?keywords=php-ds&searchon=names&suite=all§ion=all Options:
|
|
For posterity - results from my Macbook Pro 2016 (2.7GHz i7): Data set as of today's date: $ bgpq3 -4 AS-HURRICANE | wc -l
1055279
$ bgpq3 -6 AS-HURRICANE | wc -l
166103From a freshly initialised database with this data (i.e. already populated - which takes longer due to ~1m inserts), an update runs as: Hurricane Electric: [IPv4: 943875 total; 0 stale; 0 new; DB updated] [IPv6: 161275 total; 0 stale; 0 new; DB updated]
Time for net/database/processing: 10.428121/30.826060/3.132205 (secs)For something much smaller: HEAnet: [IPv4: 49 total; 0 stale; 0 new; DB updated] [IPv6: 23 total; 0 stale; 0 new; DB updated]
Time for net/database/processing: 2.158729/0.026693/0.003169 (secs) |
Thu 15 Dec 03:00:01 CET 2016
Running irrdb-cli.update-asn-db:
Processing ...
Thu 15 Dec 03:03:05 CET 2016
Running irrdb-cli.update-prefix-db:
Processing ...
Thu 15 Dec 05:29:20 CET 2016
Nick pointed out it's probably AS-HURRICANE that's chewing up all the time.
The text was updated successfully, but these errors were encountered: