Here is the requested output.  I had to kill all the other poller processes running on the system to get it to run (they were hosing the CPU).  Oddly enough, once I killed all the other processes, I didn’t any problems running it (back to being fast).  Also don’t seem to be getting the errors in the db.log when running the poller ‘one-at-a-time’.

 

 

 

From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong
Sent: Tuesday, August 11, 2015 11:52 PM
To: observium@observium.org
Subject: Re: [Observium] 'Duplicate entry' issues on vlans_fdb

 

Hi Aaron,

 

These seem to be gone from my db.log. Could you send me a ./poller.php -h 54 -m fdb-table -d ?

 

Thanks,

adam.

On 12/08/2015 05:01:53, Aaron Mayfield <amayfield@artisaninfrastructure.com> wrote:

Just today I updated to the latest and greatest (0.15.8.6882). I was several revisions behind and several database updates were done as a result. After the update, I noticed my poller.php processes started taking all the CPU, started getting gaps in the graphs, etc. I noticed thousands of these entries in db.log:


[2015/08/11 22:01:02 -0500] poller.php(21342): Failed dbQuery (#1062 - Duplicate entry '54-2083-6ef88537f91f' for key 'dev_vlan_mac'), Query: INSERT INTO `vlans_fdb` (`device_id`,`vlan_id`,`port_id`,`mac_address`,`fdb_status`) VALUES ('54','2083','220115','6ef88537f91f','learned')
[2015/08/11 22:01:02 -0500] poller.php(21342): Failed dbQuery (#1062 - Duplicate entry '54-2084-005056a927c2' for key 'dev_vlan_mac'), Query: INSERT INTO `vlans_fdb` (`device_id`,`vlan_id`,`port_id`,`mac_address`,`fdb_status`) VALUES ('54','2084','220115','005056a927c2','learned')
[2015/08/11 22:01:02 -0500] poller.php(21342): Failed dbQuery (#1062 - Duplicate entry '54-2084-a66aaf0bf4cc' for key 'dev_vlan_mac'), Query: INSERT INTO `vlans_fdb` (`device_id`,`vlan_id`,`port_id`,`mac_address`,`fdb_status`) VALUES ('54','2084','220115','a66aaf0bf4cc','learned')
[2015/08/11 22:01:02 -0500] poller.php(21342): Failed dbQuery (#1062 - Duplicate entry '54-2085-228a3d193c66' for key 'dev_vlan_mac'), Query: INSERT INTO `vlans_fdb` (`device_id`,`vlan_id`,`port_id`,`mac_address`,`fdb_status`) VALUES ('54','2085','220115','228a3d193c66','learned')
[2015/08/11 22:01:02 -0500] poller.php(21342): Failed dbQuery (#1062 - Duplicate entry '54-2086-0ee7c729643b' for key 'dev_vlan_mac'), Query: INSERT INTO `vlans_fdb` (`device_id`,`vlan_id`,`port_id`,`mac_address`,`fdb_status`) VALUES ('54','2086','220115','0ee7c729643b','learned')

If I run a poller process against a switch manually, everything seems to run fine with the exception of the fdb-table module, which is taking over 600 seconds to run.

Here is the schema of my vlans_fdb file:

mysql> show columns from vlans_fdb
-> ;
+-------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+-------+
| device_id | int(11) | NO | PRI | NULL | |
| vlan_id | int(11) | NO | PRI | NULL | |
| port_id | int(11) | YES | MUL | NULL | |
| mac_address | varchar(32) | NO | PRI | NULL | |
| fdb_status | varchar(32) | NO | | NULL | |
+-------------+-------------+------+-----+---------+-------+
5 rows in set (0.00 sec)

mysql>
mysql> show index from vlans_fdb
-> ;
+-----------+------------+--------------+--------------+-------------+-----------+-------------+---- ----+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub art | Packed | Null | Index_type | Comment |
+-----------+------------+--------------+--------------+-------------+-----------+-------------+---- ----+--------+------+------------+---------+
| vlans_fdb | 0 | dev_vlan_mac | 1 | device_id | A | 15 | ULL | NULL | | BTREE | |
| vlans_fdb | 0 | dev_vlan_mac | 2 | vlan_id | A | 18348 | ULL | NULL | | BTREE | |
| vlans_fdb | 0 | dev_vlan_mac | 3 | mac_address | A | 128440 | ULL | NULL | | BTREE | |
| vlans_fdb | 1 | device_id | 1 | device_id | A | 78 | ULL | NULL | | BTREE | |
| vlans_fdb | 1 | port_id | 1 | port_id | A | 431 | ULL | NULL | YES | BTREE | |
+-----------+------------+--------------+--------------+-------------+-----------+-------------+---- ----+--------+------+------------+---------+
5 rows in set (0.04 sec)

mysql>

Does my table structure look right? I see someone else on the list has had this same issue, but there is no indication that this should be a problem in the latest version.

What should I check? Thanks for any help.




Aaron Mayfield
Cloud Expert
Networking Specialist

12400 Hwy. 71 W. Suite 350-407
Austin, TX 78738
T. 512.600.4297
www.artisaninfrastructure.com
Partner portal: https://portal.vpdc.us
Partner support: support@artisaninfrastructure.com



This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. Please note that any views or opinions present in this email are solely those of the author and do not necessarily represent those of the company. Finally the recipient should check this email and any attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. (Proprietary & Confidential – Artisan Infrastructure, Inc. et all.)
_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error, please notify the system manager.  Please note that any views or opinions present in this email are solely those of the author and do not necessarily represent those of the company.  Finally the recipient should check this email and any attachment for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.   (Proprietary & Confidential – Artisan Infrastructure, Inc. et all.)