Sziasztok,
Valaki tudja a választ arra, hogy egy szüzen telepített WP3, amiben gyakorlatilag csak a default postok vannak benne, miért csinálja azt, hogy az adminban rákattintok bármelyik menüpontra (pl.: “Bejegyzések”) a szerveren a load elindul szép lassan felfelé. 3-6-9-12 stb.
Amikor ketten használjuk akkor az egész szervert újra kell indítani miatta.
Ezt csak a 3.0-ás WP-nél tapasztaltam, más CMS még hasonlót sem csinál. Linux/Debian 5 az alaprendszer.
Köszi a segítséget.
Szia. Hát ez érdekes probléma, mert ha folyamatosan nől a process, akkor kattintás után is dolgozna tovább a kód ami elég valószínűtlen. Én mondjuk első körben a LAMP valami szokatlan hibájára tippelnék, újra kéne húzni és úgy megnézni. A wordpressből egyébként konkrétan mely verzió(kat) próbáltad, esetleg a 3.2 RC-t is?
Tovább kutakodtam a témában és találtam egy érdekes problémát.
Valamiért használ a WP egy SQL_CALC_FOUND_ROWS és a SELECT FOUND_ROWS() sql kéréseket.
A wp_includes/query.php-ról van szó. A SQL_CALC_FOUND_ROWS alapból overload gyanús.
Találtam egy leírást az orvoslásra:
http://tech-seeker.com/blog/wordpress-3-still-using-slow-sql_calc_found_rows/
Most tesztelem, hogy valóban gyorsít-e ha átírunk néhány alapvető paramétert a query.php-ban.
Természetesen a táblák indexelése alapvető fontosságú.
Akit érdekel csatoltam a query.php módosított verzióját. ([attachment=336:query.php])
a legnagyobb para ezzel az h mindjárt itt a 3.2 inkább annak a forrását elemezd meg nézegesd…
Ez perpill a 3.1.3-as. 
A 3.2 beta1-ben ugyanúgy benne van a SQL_CALC_FOUND_ROWS 
Szeretem az ilyen botcsinálta kód turkászokat.
Nyilván hülye emberek dolgoznak az Automatticnál, és azt a 20.000.000 blogot a wp.com-on szarul működtetik, szar kóddal…
Gondolkodjatok már egy picit.
kikérem magamnak a többesszámot igenis van átírt wp-m, de az még 2.3ra épült és nem is tudom mi az ami még eredeti belőle de ez nem ide tartozik… ettől függetlenül a wp kódjában azért akadnak hibák nem azért mert emberek hülyék, hanem mert nagy rendszer amit rengetegen fejlesztenek. Tehát simán lehetnek logikai síkon elcsúszott dolgok is… de lekódolni is irgalmatlan összetett ezeket a dolgokat… szóval csak annyit, hogy persze nem tökéletes a rendszer, de hát melyik az. viszont használható, viszonylag easy-to-use még komolyabb környezetben is…
ami konkrétan feltűnik (memory leak stb) azokat a hibákat meg kell próbálni lekövetni, be kell jelenteni és ha kritikus akkor a köv. kiadásban befoltozzák…
Nem neveztünk hülyének senkit.
A kód nem szar, csak bizonyos része felesleges memóriát visz el.
Visszatérve a probléma megoldásra:
SELECT COUNT() ilyet sem feltétlenül használunk.
Elnézve a táblák szerkezetét nincs egységes id mező!!
Ãgy nem tudunk semmi mást rakni a * helyére.
Ezért a query.php-ban a módosítást követően lett egy ilyen SELECT COUNT() sor, én ezt kikommenteztem teszt jelleggel.
// $found_posts_query = apply_filters_ref_array( 'found_posts_query', array( 'SELECT COUNT(*) FROM $wpdb->posts $join WHERE 1=1 $where $groupby $orderby', &$this ) );
Egyenlőre nincs hiba, de a szűz rendszer telepítés utáni állapot és a mostani között jelentős sebességjavulás érezhető.
Azt még nem tudom, hogy pontosan mit érint a found_posts_query lekérés de majd a tesztelés során kiderül.
Ennyit találtam róla: http://adambrown.info/p/wp_hooks/hook/found_posts_query
Amit még beállítottam a wp-config.php fileban az alábbiak voltak:
define('WP_POST_REVISIONS', false);
define('AUTOSAVE_INTERVAL', 300 );
define('EMPTY_TRASH_DAYS', 0 );
define('WP_ALLOW_REPAIR', true);
define('DISALLOW_FILE_EDIT',true);
Az optimalizálás a cél.
És természtesen WP Super Cache (sokat segít)
Aha, csak a COUNT(*) az SQL tábla leírójából olvassa ki az értéket,
míg ha mezőt írsz bele, az valóban lefuttatja a countot.