Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: netdisco2 - vlaninventory is really slow (Oliver Gorwits)
2. Re: ND2 strange node behaviour (Nikolaos Milas)
3. vendor inventory 'unkown vendor' (Natxo Asenjo)
4. Re: vendor inventory 'unkown vendor' (Oliver Gorwits)
5. Re: netdisco2 - vlaninventory is really slow (Chris Stromsoe)
6. Re: netdisco2 - vlaninventory is really slow (Oliver Gorwits)
--- Begin Message ---
Hi Chris,
Many thanks for this :)
In answer to your question, usually we write the DBIx::Class calls to
get the right result (in some reasonable time ;-) and revisit to tune
later. Most of the time we're working on features.
So I do appreciate this contribution and will refactor accordingly when
I get a moment. It seems we're doing a self-join on device_vlan table,
possibly unnecessarily, which you've eliminated.
If you want to poke at any other queries, please feel free :-)
p.s. I assume you're using "DBIC_TRACE=1 DBIC_TRACE_PROFILE=console"
for this?
regards,
oliver.
On 2014-05-16 05:22, Chris Stromsoe wrote:
Pulling the vlan inventory report in Netdisco2 is really slow in my
installation (postgresql 9.1, up to date nd2).
The code in VlanInventory.pm produces this query:
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip ) ),
COUNT( ports.vlan )
FROM device_vlan me
LEFT JOIN device_port_vlan ports
ON ( ports.ip = me.ip AND ports.vlan = me.vlan )
LEFT JOIN device_vlan vlan
ON ( vlan.ip = ports.ip AND vlan.vlan = ports.vlan )
WHERE ( vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description
It's called once, wrapped in a COUNT(), by
return unless $set->count;
then once again when feeding to the output template.
In my installation, each query run takes around 35s, for an average
total
pageload of 70s.
Rewriting the SQL as
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip ) ),
COUNT( ports.vlan )
FROM device_vlan vlan, device_port_vlan ports
WHERE ( ports.ip = vlan.ip AND ports.vlan = vlan.vlan AND
vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description;
drops the pageload time to around 1.5s and seems to produce the same
output.
I'm not familiar with DBIC. Is anybody already working on adjusting
the
code to produce more performant SQL on the backend?
-Chris
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For
FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
On 29/4/2014 7:53 μμ, Nikolaos Milas wrote:
I installed the new version but it did not correct the problem I
described. The situation remains as before.
I have now installed latest Netdisco but the problem persists.
-----------------------------------------------------------------------------------
Software Version
-----------------------------------------------------------------------------------
App::Netdisco 2.027004
DB Schema v38
Dancer 1.3119
Bootstrap 2.3.1
PostgreSQL PostgreSQL 8.4.20 on x86_64-redhat-linux-gnu,
compiled by GCC gcc (GCC) 4.4.7 20120313 (Red Hat
4.4.7-4), 64-bit.
DBI 1.609, DBD::Pg 2.15.1
SNMP::Info 3.13
Perl 5.010001
-----------------------------------------------------------------------------------
Best regards,
Nick
--- End Message ---
--- Begin Message ---
hi,
First post.
I have successfully deployed App::Netdisco on a centos 6.5 vm (32bits)
following the instructions on https://metacpan.org/pod/App::Netdisco.
Actually, because this vm is locked from the internet, I prepared a
minicpan mirror on my laptop and installed it from there. Then I found out
that in order to bootstrap the installation I needed internet access for
the mibs. So I installed the app first in my laptop (which has internet
access) and copied the netdisco-mibs folder to the centos 6.5. My laptop is
running fedora 20 amd64.
In my laptop installation I saw vendor information after discovering
devices. On the centos vm the vendor inventory is consistently 'unknown
vendor'.
I have reloaded both the daemon as the web inteface several times.
This is not a huge issue, but it is nice to have of course.
How can I get it to work?
TIA.
Regards,
--
Groeten,
natxo
--- End Message ---
--- Begin Message ---
Hi Natxo,
Please can you check the location and permissions on the netdisco-mibs
folder?
It should be in the netdisco user home area:
/home/netdisco/netdisco-mibs
and should have the same user/group as the netdisco installation, for
all files and folders within.
You can run the netdisco-do command or daemons with INFO_TRACE=1
environment variable set and should see some debugging that it's found
the MIBs directories.
regards,
oliver.
On 2014-05-19 15:14, Natxo Asenjo wrote:
hi,
First post.
I have successfully deployed App::Netdisco on a centos 6.5 vm
(32bits)
following the instructions on https://metacpan.org/pod/App::Netdisco
[1].
Actually, because this vm is locked from the internet, I prepared a
minicpan mirror on my laptop and installed it from there. Then I
found
out that in order to bootstrap the installation I needed internet
access for the mibs. So I installed the app first in my laptop (which
has internet access) and copied the netdisco-mibs folder to the
centos
6.5. My laptop is running fedora 20 amd64.
In my laptop installation I saw vendor information after discovering
devices. On the centos vm the vendor inventory is consistently
'unknown vendor'.
I have reloaded both the daemon as the web inteface several times.
This is not a huge issue, but it is nice to have of course.
How can I get it to work?
TIA.
Regards,
--
Groeten,
natxo
Links:
------
[1] https://metacpan.org/pod/App::Netdisco
--- End Message ---
--- Begin Message ---
Thanks. I didn't know about the built-in DBIC tracing, and used
postgresql query logging to get the results of what was being sent to the
database, then tested different queries against the query planner. If I
find any other slow spots in my environment I'll let you know. I'll try
to provide patches (instead of "this SQL works better than that SQL") if I
manage to figure out how DBIC constructs queries.
-Chris
On Fri, 16 May 2014, Oliver Gorwits wrote:
Hi Chris,
Many thanks for this :)
In answer to your question, usually we write the DBIx::Class calls to
get the right result (in some reasonable time ;-) and revisit to tune
later. Most of the time we're working on features.
So I do appreciate this contribution and will refactor accordingly when
I get a moment. It seems we're doing a self-join on device_vlan table,
possibly unnecessarily, which you've eliminated.
If you want to poke at any other queries, please feel free :-)
p.s. I assume you're using "DBIC_TRACE=1 DBIC_TRACE_PROFILE=console" for
this?
regards,
oliver.
On 2014-05-16 05:22, Chris Stromsoe wrote:
Pulling the vlan inventory report in Netdisco2 is really slow in my
installation (postgresql 9.1, up to date nd2).
The code in VlanInventory.pm produces this query:
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip ) ),
COUNT( ports.vlan )
FROM device_vlan me
LEFT JOIN device_port_vlan ports
ON ( ports.ip = me.ip AND ports.vlan = me.vlan )
LEFT JOIN device_vlan vlan
ON ( vlan.ip = ports.ip AND vlan.vlan = ports.vlan )
WHERE ( vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description
It's called once, wrapped in a COUNT(), by
return unless $set->count;
then once again when feeding to the output template.
In my installation, each query run takes around 35s, for an average
total
pageload of 70s.
Rewriting the SQL as
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip ) ),
COUNT( ports.vlan )
FROM device_vlan vlan, device_port_vlan ports
WHERE ( ports.ip = vlan.ip AND ports.vlan = vlan.vlan AND
vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description;
drops the pageload time to around 1.5s and seems to produce the same
output.
I'm not familiar with DBIC. Is anybody already working on adjusting
the
code to produce more performant SQL on the backend?
-Chris
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For
FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi Chris,
On 2014-05-19 20:38, Chris Stromsoe wrote:
Thanks. I didn't know about the built-in DBIC tracing, and used
postgresql query logging to get the results of what was being sent to
the database, then tested different queries against the query
planner.
If I find any other slow spots in my environment I'll let you know.
I'll try to provide patches (instead of "this SQL works better than
that SQL") if I manage to figure out how DBIC constructs queries.
Heh, funnily enough my editor is open right now, working on your
submission :-)
Many thanks, do let us know if you see any other areas where we can
improve. Sounds like you have more SQL-fu than me, at least!
Would be happy to see you in the IRC channel (#netdisco on freenode) if
you want to chat in person.
regards,
oliver.
-Chris
On Fri, 16 May 2014, Oliver Gorwits wrote:
Hi Chris,
Many thanks for this :)
In answer to your question, usually we write the DBIx::Class calls
to get the right result (in some reasonable time ;-) and revisit to
tune later. Most of the time we're working on features.
So I do appreciate this contribution and will refactor accordingly
when I get a moment. It seems we're doing a self-join on device_vlan
table, possibly unnecessarily, which you've eliminated.
If you want to poke at any other queries, please feel free :-)
p.s. I assume you're using "DBIC_TRACE=1 DBIC_TRACE_PROFILE=console"
for this?
regards,
oliver.
On 2014-05-16 05:22, Chris Stromsoe wrote:
Pulling the vlan inventory report in Netdisco2 is really slow in my
installation (postgresql 9.1, up to date nd2).
The code in VlanInventory.pm produces this query:
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip )
),
COUNT( ports.vlan )
FROM device_vlan me
LEFT JOIN device_port_vlan ports
ON ( ports.ip = me.ip AND ports.vlan = me.vlan )
LEFT JOIN device_vlan vlan
ON ( vlan.ip = ports.ip AND vlan.vlan = ports.vlan )
WHERE ( vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description
It's called once, wrapped in a COUNT(), by
return unless $set->count;
then once again when feeding to the output template.
In my installation, each query run takes around 35s, for an average
total
pageload of 70s.
Rewriting the SQL as
SELECT vlan.vlan, vlan.description, COUNT( DISTINCT( ports.ip )
),
COUNT( ports.vlan )
FROM device_vlan vlan, device_port_vlan ports
WHERE ( ports.ip = vlan.ip AND ports.vlan = vlan.vlan AND
vlan.description != 'NULL' )
GROUP BY vlan.vlan, vlan.description;
drops the pageload time to around 1.5s and seems to produce the
same
output.
I'm not familiar with DBIC. Is anybody already working on
adjusting
the
code to produce more performant SQL on the backend?
-Chris
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For
FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing
platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For
FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
