This is probably due to the use of information_schema to get the information about tables. Can you try adding $cfg['Servers'][$i]['DisableIS'] = true; in your config.inc.php file for this server and see if the situation improves?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Madhura, thanks for the config, but it did not fix the problem.
After investigating further, I notice the AJAX call to navigation.php actually returns a 504, so the request never completes. Debugging led me to find the AJAX request dies on this line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Although you may call this an edge case, there is no reason phpMyAdmin should not be able to support 30k or 30m tables. InnoDB has an upper limit of 4 billion tables.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Eric,
- please try phpMyAdmin version 3.5.x to see what happens
- this is truly an edge case; may I respectfully ask why you have 30k tables? maybe the data model of this db needs a revision
- see our LICENCE, item 11: "no warranty" so maybe you need to find another tool that works for your needs
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some profiling to get an idea on where the problem is. php::mysqli_query takes more than 85% of the total time of loading child nodes. So, I am afraid there is little room for improvements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is probably due to the use of information_schema to get the information about tables. Can you try adding
$cfg['Servers'][$i]['DisableIS'] = true;in your config.inc.php file for this server and see if the situation improves?Hi Madhura, thanks for the config, but it did not fix the problem.
After investigating further, I notice the AJAX call to navigation.php actually returns a 504, so the request never completes. Debugging led me to find the AJAX request dies on this line.
We feel that 30k tables in a database is an edge case and would naturally expect slowness.
See https://wiki.phpmyadmin.net/pma/2015-06_Meeting#BUG_Supporting_huge_databases
https://github.com/phpmyadmin/phpmyadmin/commit/bd911c86586b6de2e1a0599cb87e48aede9493b9 should improve the situation when $cfg['Servers'][$i]['DisableIS'] = true;
Eric, please give feedback about this patch.
The patch still produces 504s.
Although you may call this an edge case, there is no reason phpMyAdmin should not be able to support 30k or 30m tables. InnoDB has an upper limit of 4 billion tables.
Eric,
- please try phpMyAdmin version 3.5.x to see what happens
- this is truly an edge case; may I respectfully ask why you have 30k tables? maybe the data model of this db needs a revision
- see our LICENCE, item 11: "no warranty" so maybe you need to find another tool that works for your needs
I did some profiling to get an idea on where the problem is. php::mysqli_query takes more than 85% of the total time of loading child nodes. So, I am afraid there is little room for improvements.
Btw, my tests were carried on with 'DisableIS' = true; and the database has about 27k tables.
These are my observations
With 'DisableIS' = true
Time for php::mysqli_query = 58s
Total time = 67s
~ 87%
With 'DisableIS' = false
Time for php::mysqli_query = 302s
Total time = 309s
~ 98%
Last edit: Madhura Jayaratne 2015-06-11