You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2010-04-17 03:00:57

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Extremely slow when viewing Central>Inventory>Computers

Virtual Machine running Centos5.4 on ESXi 4.0
2 CPUs x 2.39 Ghz
4GB ram

Running:

OCSNG Ver. 1.02
GLPI Ver. 0.72.3

MySQL Database size is 26MB

446 Computer objects

--

when i click to view computer inventory it used to take only ~10 seconds to load.

now when i click to view computer inventory it takes ~1 minute to load. TOP shows mysqld service eating up the cpu.

performance was good -- until i passed ~250 computer objects.

--

Are there any optimizations out there i can follow for tuning apache / mysql / php for ocsng + glpi?

Offline

#2 2010-04-17 09:03:25

remi
GLPI-DEV
From: Champagne
Registered: 2007-04-28
Posts: 7,127
Website

Re: Extremely slow when viewing Central>Inventory>Computers

Try mysqltunner which give you tips for MySQL optimization.

+


Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/

Offline

#3 2010-04-20 01:52:55

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Re: Extremely slow when viewing Central>Inventory>Computers

Here's my mysqltuner.pl output.

Offline

#4 2010-04-20 01:53:59

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Re: Extremely slow when viewing Central>Inventory>Computers

>>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
>>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
>>  Run with '--help' for additional options and output filtering
[..] Successfully authenticated with no password - SECURITY RISK!

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 13M (Tables: 251)
[--] Data in InnoDB tables: 19M (Tables: 24)
[--] Data in MEMORY tables: 3M (Tables: 4)
[..] BDB is enabled but isn't being used
[..] Total fragmented tables: 5

-------- Performance Metrics -------------------------------------------------
[--] Up for: 49m 6s (6K q [2.118 qps], 81 conn, TX: 6M, RX: 586K)
[--] Reads / Writes: 64% / 36%
[--] Total buffers: 2.1G global + 12.4M per thread (100 max threads)
[OK] Maximum possible memory usage: 3.3G (84% of installed RAM)
[OK] Slow queries: 0% (18/6K)
[OK] Highest usage of available connections: 16% (16/100)
[OK] Key buffer size / total MyISAM indexes: 2.0G/10.6M
[OK] Key buffer hit rate: 99.8% (9M cached / 17K reads)
[OK] Query cache efficiency: 58.3% (2K cached / 4K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (2 temp sorts / 149 sorts)
[..] Joins performed without indexes: 18
[..] Temporary tables created on disk: 35% (129 on disk / 361 total)
[OK] Thread cache hit rate: 80% (16 created / 81 connections)
[OK] Table cache hit rate: 34% (136 open / 394 opened)
[OK] Open file limit used: 19% (216/1K)
[OK] Table locks acquired immediately: 100% (3K immediate / 3K locks)
[..] InnoDB data size / buffer pool: 19.8M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Add skip-bdb to MySQL configuration to disable BDB
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    innodb_buffer_pool_size (>= 19M)

Offline

#5 2010-04-20 01:58:15

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Re: Extremely slow when viewing Central>Inventory>Computers

i've tried resolving

skip-bdb - no affect

OPTIMIZE TABLE - ran on all tables in ocsweb + glpi db's and somehow it corrupted the ocsweb db so i had to restore from a snapshot

join_buffer_size - increased until mysqltuner.pl no longer outputted but performance still slow

tmp_table_size -  increased until mysqltuner.pl no longer outputted but performance still slow

max_heap_table_size - increased until mysqltuner.pl no longer outputted but performance still slow

innodb_buffer_pool_size - increased until mysqltuner.pl no longer outputted but performance still slow

Offline

#6 2010-04-20 02:00:45

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Re: Extremely slow when viewing Central>Inventory>Computers

remi,

with your >130k computer objects, how long does your computer inventory page take to load?

Offline

#7 2010-04-20 02:55:47

glpiuser2
Member
Registered: 2010-04-17
Posts: 6

Re: Extremely slow when viewing Central>Inventory>Computers

just found the cause.

it's the tracker - switch / tracker - hardware ports listed in the columns of the computer inventory page.

removed those two columns and performance is back to down to ~5 seconds to load.

Offline

#8 2010-04-20 23:01:49

JMD
GLPI - Lead
Registered: 2004-09-13
Posts: 9,180
Website

Re: Extremely slow when viewing Central>Inventory>Computers

Ok i close


JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au  projet GLPI   : Soutenir

Offline

Board footer

Powered by FluxBB