I install APC it makes some difference in speed. I turned on slow-message
logging for mySQL and that log file is filling up fast! Some examples:
# u...@host: reformedword[reformedword] @ localhost []
# Query_time: 9 Lock_time: 2 Rows_sent: 5 Rows_examined: 5
SELECT /* SMW::deleteSubject::Nary Aquatiki */ smw_id FROM `rw_smw_ids`
WHERE smw_title='' AND smw_namespace='712136' AND smw_iw=':smw';
# u...@host: reformedword[reformedword] @ localhost []
# Query_time: 46 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
DELETE /* SMW::deleteSubject::Atts2 Aquatiki */ FROM `rw_smw_atts2` WHERE
s_id = '230051';
# Time: 100213 3:02:55
# u...@host: reformedword[reformedword] @ localhost []
# Query_time: 55 Lock_time: 1 Rows_sent: 0 Rows_examined: 0
INSERT /* SMW::updateRel2Data 216.129.119.43 */ INTO `rw_smw_rels2`
(s_id,p_id,o_id) VALUES ('202900','4987','
202901'),('202900','5064','5065'),('202900','5463','202899'),('202900','135','289060'),('289060','225879','304'
),('202900','135','289061'),('289061','225879','118784'),('289061','225881','331'),('202900','135','289062'),('
289062','225879','119703'),('289062','225881','386'),('202900','135','289065'),('289065','225879','277'),('2029
00','135','289066'),('289066','225879','207525'),('289066','225881','385'),('202900','135','289067'),('289067',
'225879','119048'),('289067','225881','225124'),('202900','135','601368'),('601368','225879','584'),('601368','
225881','387'),('202900','1011','1417340'),('1417340','225879','1425'),('202900','1011','1417342'),('1417342','
225879','1446'),('1417342','225881','1174937'),('202900','1011','1663477'),('1663477','225879','1182228'),('166
3477','225881','209798'),('202900','1464','1663478'),('1663478','225879','926'),('1663478','225881','375867'),(
'202900','1464','1663479'),('1663479','225879','1490'),('202900','1464','1663480'),('1663480','225879','223216'
),('1663480','225881','687547'),('202900','1464','1663481'),('1663481','225879','845'),('202900','1464','222487
0'),('2224870','225879','1651'),('202900','6840','4980'),('202900','6906','5727'),('202900','223343','6503');
# Time: 100213 3:03:12
# u...@host: reformedword[reformedword] @ localhost []
# Query_time: 36 Lock_time: 19 Rows_sent: 1 Rows_examined: 1948
SELECT /* SMW::getQueryResult 216.129.119.43 */ COUNT(DISTINCT t0.smw_id)
AS count FROM `rw_smw_ids` AS t0 IN
NER JOIN `rw_smw_rels2` AS t2 ON t0.smw_id=t2.s_id INNER JOIN `rw_smw_rels2`
AS t5 ON t2.o_id=t5.s_id INNER JOI
N `rw_smw_inst2` AS t7 ON t2.s_id=t7.s_id WHERE t2.p_id='1464' AND
t5.p_id='225879' AND t5.o_id='177656' AND t
7.o_id='3304' LIMIT 10001;
# Time: 100213 3:03:30
>
> Regarding PHP, I don't think that a memory limit of more than 50MB or
> maximally 100MB can be recommended to any public site. What ever dies
> beyond
> this point cannot be saved. On the other hand, PHP Out of Memory issues are
> hard to track since there cause is often not the function that adds the
> final
> byte that uses up all memory. You have seen this in your logs.
>
> One general thing that should be done on larger sites (actually on all
> sites!)
> is bytecode caching, see [1]. This significantly reduces the impact that
> large
> PHP files as such have on your memory requirements.
>
> Out of mem issues usually result in blank pages that can only be edited by
> changing the URL manually to use the edit action. Finding these pages is
> crucial to track down the problem. In the context of SMW, I have seen
> memory
> issues when inline queries return a long list of results each of which
> contains a lot of values. This problem is worse when using templates for
> formatting, but it occurs also with tables. I have tracked down this
> problem
> to MediaWiki in my tests: manually writing a page with the contents
> produced
> by the large inline query has also used up all memory, even without SMW
> being
> involved. If this is the case on your wiki, then my only advise is to
> change
> the SMW settings to restrict the size of query outputs so that pages cannot
> become so large. If this is not the problem you have, then it is important
> to
> find out which pages cause the issues in your wiki. Note that problems that
> are caused by MediaWiki jobs could also appear for random pages since they
> are
> not depending on the page contents.
>
>
> Regarding MySQL, you should activate and check the slow query logging of
> MySQL. It will create log files that show you which queries took
> particularly
> long. This can often be used to track down problematic queries and to do
> something to prevent them.
>
>
> If you experience general site overload in a burst-like fashion then it
> might
> be that some over-zealous crawler is visiting your site, possibly
> triggering
> complicated activities. Check your Apache logs to see if you have high
> loads
> for certain robots or suspicious user agents, especially on special pages
> like
> Ask. Update your robots.txt to disallow crawlers to browse all results of
> an
> inline query (crawlers have been observed to do this).
>
> -- Markus
>
> [1] http://www.mediawiki.org/wiki/User:Robchurch/Performance_tuning
>
>
>
> --
> Markus Krötzsch <mar...@semantic-mediawiki.org>
> * Personal page: http://korrekt.org
> * Semantic MediaWiki: http://semantic-mediawiki.org
> * Semantic Web textbook: http://semantic-web-book.org
> --
>
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
