Re: [Toolserver-l] [Toolserver-announce] Maintenance-window for webservers Monday 20:00-22:00 UTC
Hello all Am Freitag 28 September 2012, 00:49:32 schrieb DaB.: > Hello all, > > like announced on last Sunday I hereby announce a maintenance-window for > > Monday, 20:00-22:00 UTC for the web-servers. > > I will reboot hemlock a few times to try to find out why the web-servers > are not working if hemlock is away (and if I find it, I will fix it). All > web-tools will failing in times when hemlock is (re-)booting, other > sub-systems (like SGE) should working normal. The maintenance is done. I have identified the nfs-service at hemlock as the root of the problem. However I confused by the result: If I stop the nfs- service completely the webservers fail (like expected). If I remove all nfs- shares on hemlock and start the nfs-service the webservers fail too (also ok). But it is not possible to identify the share that cause the problem, because if I remove each share separately and restart the nfs-service afterwards the webservers did working (some times they needed a moment, but at the end they worked). I have to think about this first before I can take further steps. All maintenances for today are done. You can work normal now again :-). > Sincerely, > DaB. Sincerely, DaB. -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 signature.asc Description: This is a digitally signed message part. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Maintenance of s2 and s5 Monday, 1st October
Hello, the maintenance has been finished successfully. Cheers nosy On Sun, 30 Sep 2012, Marlen Caemmerer wrote: Date: Sun, 30 Sep 2012 20:36:46 From: Marlen Caemmerer To: toolserver-l@lists.wikimedia.org Cc: toolserver-annou...@lists.wikimedia.org Subject: Maintenance of s2 and s5 Monday, 1st October Hello, as tomorrow is maintenance window anyway I will add more disk space to s2 and s5. In the time of the work the databases s2 and s5 will not be available. This will take about 1-1.5 hours and I will do it when DaB checks the hemlock & web server interaction at 20 - 22 UTC. Cheers nosy ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] [Toolserver-announce] Reboot of the linux-boxes at Monday 19:05 UTC
Hello all, Am Sonntag 30 September 2012, 15:36:58 schrieb DaB.: > Hello all, > > because of a kernel-upgrade I have to reboot our linux-boxes (nightshade, > yarrow and mayapple). This will happen tomorrow, > > Monday, 19:05 UTC. all boxes were successful rebooted. Please remember that there are also the following maintenance today: -On the webservers (by dab). -On s2/s5 (by nosy). Both beginning at 20:00 UTC. > > Sincerely, > DaB. Sincerely, DaB. -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 signature.asc Description: This is a digitally signed message part. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Future of the toolserver
On Mon, Oct 1, 2012 at 8:12 AM, Platonides wrote: > Note that it's false that MediaWiki doesn't perform joins. > There are many of them. The statement about that was (probably) talking > about cross-db joins. Yes, that's right, I was talking about joins between user databases and the replicated databases containing the live wiki data. The quote I am thinking of was posted by Ryan Lane to toolserver-l on Sep 26. It said, "We currently have no plans for having the user databases on the same servers as the replicated databases. Direct joins will not be possible, so tools will need to be modified.". As you have pointed out in a previous message, the reason behind many cross-db joins on toolserver is that users are unable to create tables within the replicated databases. That's expected - the replicated databases need to match the live ones - but the natural solution is to have user databases on the same servers. This also leads to the problem you pointed out: > Even for MediaWiki extensions, not having user tables can be hard. Yes, I agree. At [1], there is currently this claim about cross-db joins on labs: "Unlikely, that logic should be handled within the application. It's impossible to shared data otherwise, as well as the extra overhead on the database servers which are effectively a shared component. DamianZaremba (talk) 11:13, 27 September 2012 (UTC)" I am not sure what "within the application" means, but if someone is writing a Mediawiki extension and needs another table or needs a schema change, it is not obvious to me right now how they would be able to do a join between a user table for their extension and the replicated tables from the live projects. And those joins would certainly be "within the application". But I expect that few toolserver users were/are working on mediawiki extensions. For non-extension projects that have a lot of data, using a database server is the only reasonable solution. Just as a point of data, the "logging" table for the WP 1.0 project on toolserver, which has records for article assessments on enwiki, has about 46 million rows in a user database. - Carl 1: http://www.mediawiki.org/wiki/Wikimedia_Labs/Toolserver_features_wanted_in_Tool_Labs ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: >> Thanks. I don't want to fiddle to much with SGE's in- >> testines, so I will probably either use "| mail timl" in my >> script or have my MUA insert the log in the status mail. >> I looked if I could submit this totally fascinating and >> innovative idea of mailing the output as a RFE upstream, but >> amazingly I didn't see a bugtracker at Oracle :-). I would >> even have had another idea: Impromptu jobs à la "echo true | >> at now" :-). > Oracle closed-sourced it. There are a number of forks. > Quick link: http://gridengine.org/blog/2011/11/23/what-now/ If these two issues are the only things missing in SGE, I think we can stay with it :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
On 01/10/12 14:19, Tim Landscheidt wrote: > Thanks. I don't want to fiddle to much with SGE's in- > testines, so I will probably either use "| mail timl" in my > script or have my MUA insert the log in the status mail. > > I looked if I could submit this totally fascinating and > innovative idea of mailing the output as a RFE upstream, but > amazingly I didn't see a bugtracker at Oracle :-). I would > even have had another idea: Impromptu jobs à la "echo true | > at now" :-). > > Tim Oracle closed-sourced it. There are a number of forks. Quick link: http://gridengine.org/blog/2011/11/23/what-now/ ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: >>> Please see the documentation on Toolserver wiki [1] to set this up. It uses >>> a command of -m with another variable depending on when you want mail sent. >>> [1] >>> https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub >>> [...] >> That just sends notifications about the job's status, not >> the job's output itself. > No, there's no such option. > I looked into it recently. We could get that by adding a final script > which mails the user the output file if qstat -j $JOB_ID | grep -q > mail_options:.*e. Thanks. I don't want to fiddle to much with SGE's in- testines, so I will probably either use "| mail timl" in my script or have my MUA insert the log in the status mail. I looked if I could submit this totally fascinating and innovative idea of mailing the output as a RFE upstream, but amazingly I didn't see a bugtracker at Oracle :-). I would even have had another idea: Impromptu jobs à la "echo true | at now" :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Future of the toolserver
On 01/10/12 01:28, Carl (CBM) wrote: > * "User databases will not be able to be joined against replicated > databases." The reasoning behind this seems to be a misunderstanding > of the role of "application logic". For Mediwiki itself, which works > with only a few articles at a time, joins can be efficiently simulated > within Mediawiki itself, or by making changes to the database schema > on the live servers. For a toolserver application that works with > millions of articles in a single query, it is silly to essentially > re-implement a SQL engine in the application logic - joins of this > size, which may require filesorts, should be done at the database > server level, not at the application level. That's why we use a > database server in the first place. Note that it's false that MediaWiki doesn't perform joins. There are many of them. The statement about that was (probably) talking about cross-db joins. But the reason for using different dbs on toolserver is based on user permissions, not in that those tables conceptually should go with the data in the wiki db. > Looking at the discussions about labs in the past few days, it seems > clear to me that labs will be useful for some projects, particularly > for developing Mediawiki extensions. Even for MediaWiki extensions, not having user tables can be hard. If your extension needs a new table, with you can create it at another db and link them with $wgSharedTables (a configuration change, without touching the extension code). Without that, testing one extension with an additional table would need it to be created in the master wiki db! (plus have a user with permissions to write it, and all related maintenance) ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reasons for not migrating to Tool Lab
(anonymous) wrote: >> Even more: If Labs replication isn't bound by Toolserver >> tradition, it would be *very* nice not to fragment the data >> according to the different WMF clusters, plus Commons or >> not, plus (separate) user databases or not, but have one >> cluster where users can join as logic suggests. As Toolser- >> ver merges Commons onto other clusters already, this seems >> to be possible with MySQL. > It's possible, you just need bigger servers which can hold all dbs. > (plus some master/slave replication for user tables) > I suppose it will use the same clusters as WMF. After all, there's a > reason the WMF clusters needed to be splitted. Sure, but tools outside production probably don't need that extra millisecond those clusters are aiming for. Take the Analytics Team for example: They happily consider different tools because they have different goals. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reasons for not migrating to Tool Lab
On 01/10/12 13:03, Tim Landscheidt wrote: > Even more: If Labs replication isn't bound by Toolserver > tradition, it would be *very* nice not to fragment the data > according to the different WMF clusters, plus Commons or > not, plus (separate) user databases or not, but have one > cluster where users can join as logic suggests. As Toolser- > ver merges Commons onto other clusters already, this seems > to be possible with MySQL. > > Tim It's possible, you just need bigger servers which can hold all dbs. (plus some master/slave replication for user tables) I suppose it will use the same clusters as WMF. After all, there's a reason the WMF clusters needed to be splitted. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
On 01/10/12 13:21, Tim Landscheidt wrote: > (anonymous) wrote: > >> Please see the documentation on Toolserver wiki [1] to set this up. It uses >> a command of -m with another variable depending on when you want mail sent. > >> [1] >> https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub >> [...] > > That just sends notifications about the job's status, not > the job's output itself. > > Tim No, there's no such option. I looked into it recently. We could get that by adding a final script which mails the user the output file if qstat -j $JOB_ID | grep -q mail_options:.*e. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: > Please see the documentation on Toolserver wiki [1] to set this up. It uses a > command of -m with another variable depending on when you want mail sent. > [1] > https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub > [...] That just sends notifications about the job's status, not the job's output itself. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
Hi Tim, Please see the documentation on Toolserver wiki [1] to set this up. It uses a command of -m with another variable depending on when you want mail sent. [1] https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub Cheers, James On 01/10/2012, at 9:05 PM, Tim Landscheidt wrote: > Hi, > > is there an option to have qsub/qcronsub mail me the output > of a command instead of writing it to disk? Something simi- > lar to regular cron/at? > > TIA, > Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] How to have qsub mail output?
Hi, is there an option to have qsub/qcronsub mail me the output of a command instead of writing it to disk? Something simi- lar to regular cron/at? TIA, Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reasons for not migrating to Tool Lab
(anonymous) wrote: >> We currently have no plans for having the user databases on the same >> servers as the replicated databases. Direct joins will not be >> possible, so tools will need to be modified. > This is unfortunate, and a huge step backwards from the situation on > the toolserver. > For example, the project I maintain on toolserver (the enwiki WP 1.0 > assessment data) has user database tables with several million rows of > data about articles, from which it needs to select the data for pages > from fixed categories on the wiki, which themselves could have a few > thousand members. The natural way to do this is to join against the > categorylinks table. Any non-join solution is going to be much, much > less efficient. > A key role of the toolserver setup was that it allowed these sorts of > joins. Web hosting is cheap and data about the live wiki is already > available in non-joinable form through the API with no replag. Even more: If Labs replication isn't bound by Toolserver tradition, it would be *very* nice not to fragment the data according to the different WMF clusters, plus Commons or not, plus (separate) user databases or not, but have one cluster where users can join as logic suggests. As Toolser- ver merges Commons onto other clusters already, this seems to be possible with MySQL. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
