-- "Coffee should be black as Hell, strong as death, and sweet as love." ~ Turkish Proverb
On Monday 09 July 2007 23:26:42 Jeff Griffiths wrote:
-- "Coffee should be black as Hell, strong as death, and sweet as love." ~ Turkish Proverb
Yes, it worked flawlessly a few minutes ago. This raises a question: *Too much* information is displayed when a database error occurs, for example: "The MySQL error was: Lost connection to MySQL server at 'reading initial communication packet', system error: 111. Currently, the username is drupal and the database server is drupaldb2.osuosl.org." IMHO, a more generic message would be more appropriate. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
On 7/9/07, Vasileios Lourdas <lourdas_v@yahoo.gr> wrote:
This raises a question: *Too much* information is displayed when a database error occurs, for example:
"The MySQL error was: Lost connection to MySQL server at 'reading initial communication packet', system error: 111.
Currently, the username is drupal and the database server is drupaldb2.osuosl.org."
IMHO, a more generic message would be more appropriate.
Now it says: 'Gremlins ate the DB server, but Druplicon is fighting them. Drupal.org should be back soon.' Awesome.
On Tuesday 10 July 2007 06:07, Jeff Griffiths wrote:
'Gremlins ate the DB server, but Druplicon is fighting them. Drupal.org should be back soon.'
I didn't get to see the message. I like gremlins. I am sure it was not them! It must have been some other (alien?) species. A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
The down time seriously hinders my patch reviewing -- I tried for 30 minutes today, but I simply couldn't get two pages to load in a row (two reviews were lost). Instead of reviewing patches the next couple of days, I'm going to dedicate my time to help with the infrastructure instead. -- Dries Buytaert :: http://www.buytaert.net/
On 10 Jul 2007, at 17:09, Dries Buytaert wrote:
The down time seriously hinders my patch reviewing -- I tried for 30 minutes today, but I simply couldn't get two pages to load in a row (two reviews were lost). Instead of reviewing patches the next couple of days, I'm going to dedicate my time to help with the infrastructure instead.
Gerhard, I'd like to take a lead in managing a small team of people that are willing to help with code changes or other things that don't require shell access. It would be great if you could give us some starting points. What are the steps required to tackle this, and what steps can we open up to more people? Thanks, -- Dries Buytaert :: http://www.buytaert.net/
Can we provide you guys with a temporary mirror until you get the current setup straightened out? www2.drupal.org or something? I'm offering. Jonathan Lambert On 7/10/07, Dries Buytaert <dries@buytaert.net> wrote:
On 10 Jul 2007, at 17:09, Dries Buytaert wrote:
The down time seriously hinders my patch reviewing -- I tried for 30 minutes today, but I simply couldn't get two pages to load in a row (two reviews were lost). Instead of reviewing patches the next couple of days, I'm going to dedicate my time to help with the infrastructure instead.
Gerhard, I'd like to take a lead in managing a small team of people that are willing to help with code changes or other things that don't require shell access. It would be great if you could give us some starting points. What are the steps required to tackle this, and what steps can we open up to more people?
Thanks,
-- Dries Buytaert :: http://www.buytaert.net/
-- Jonathan Lambert Principal & CEO Email: j@workhabit.com Phone: 415-376-7274 WorkHabit, Inc. (Formerly FireBright, Inc.) http://www.workhabit.com/ http://www.workhabit.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Lambert schrieb:
Can we provide you guys with a temporary mirror until you get the current setup straightened out? www2.drupal.org or something?
I'm offering.
Thanks for the offer, but I don't really see how this should work? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlAZAfg6TFvELooQRAiIzAJ9UZvK1ugTEyXN4912Y3cbGZG+xbwCfVyO/ F8Y1g2W1yLRoLWtXqjpQavk= =USzn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dries Buytaert schrieb:
On 10 Jul 2007, at 17:09, Dries Buytaert wrote:
The down time seriously hinders my patch reviewing -- I tried for 30 minutes today, but I simply couldn't get two pages to load in a row (two reviews were lost). Instead of reviewing patches the next couple of days, I'm going to dedicate my time to help with the infrastructure instead.
Gerhard, I'd like to take a lead in managing a small team of people that are willing to help with code changes or other things that don't require shell access. It would be great if you could give us some starting points. What are the steps required to tackle this, and what steps can we open up to more people?
Dries, it is very nice to offer some of your not so copious spare time for this good cause. Sadly, there actually isn't that much you, I, or any OSUOSL outsider can do when it comes to our hardware and its setup. After discussing your offer with Narayan, we agreed that it would be best if you do that what you can do best: review patches. Especially patches which would help our infrastructure. The number one patch to review is David's master-slave patch at: http://drupal.org/node/147160 Since we can't move drupal.org to Drupal 6 right now, we'd actually need a Drupal 5 version of this, thus there shouldn't be too much reworking. It would probably be best if we'd just send specific queries to the slaves in a round-robin fashion. Any resulting patch should be tested a lot especially for inserts and updates when the server is under high load. There are also a number of other performance related patches in the patch queue. These won't help use immediately, but will in the long run. Of course, there's always the game of "review slow sql queries" to be played. The project module has a lot on offer and we can provide slow query logs. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk/vffg6TFvELooQRAr0oAKCSKy5mIDKMvo+Nz9gNeSm4WiA/awCgm1SU ZaYWtwN3YL4/EXFhrcCtQ8A= =oV5E -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
It would probably be best if we'd just send specific queries to the slaves in a round-robin fashion.
Round-robin requires process coordination. That's why my patch randomly chooses the slave server. Random distribution should be roughly uniform on a high-load site.
On 7/10/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dries Buytaert schrieb:
On 10 Jul 2007, at 17:09, Dries Buytaert wrote:
The down time seriously hinders my patch reviewing -- I tried for 30 minutes today, but I simply couldn't get two pages to load in a row (two reviews were lost). Instead of reviewing patches the next couple of days, I'm going to dedicate my time to help with the infrastructure instead.
Gerhard, I'd like to take a lead in managing a small team of people that are willing to help with code changes or other things that don't require shell access. It would be great if you could give us some starting points. What are the steps required to tackle this, and what steps can we open up to more people?
Dries, it is very nice to offer some of your not so copious spare time for this good cause. Sadly, there actually isn't that much you, I, or any OSUOSL outsider can do when it comes to our hardware and its setup.
After discussing your offer with Narayan, we agreed that it would be best if you do that what you can do best: review patches. Especially patches which would help our infrastructure.
The number one patch to review is David's master-slave patch at:
Since we can't move drupal.org to Drupal 6 right now, we'd actually need a Drupal 5 version of this, thus there shouldn't be too much reworking.
It would probably be best if we'd just send specific queries to the slaves in a round-robin fashion.
Any resulting patch should be tested a lot especially for inserts and updates when the server is under high load.
Perhaps taking Johnathan up on his offer to support a mirror of D.O. to test this patch would be prudent. There are also a number of other performance related patches in the
patch queue. These won't help use immediately, but will in the long run.
Of course, there's always the game of "review slow sql queries" to be
played. The project module has a lot on offer and we can provide slow query logs.
http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser Any chance that could get set up to run on a cron job and output somewhere regularly? Cheers, Kieran Cheers,
Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGk/vffg6TFvELooQRAr0oAKCSKy5mIDKMvo+Nz9gNeSm4WiA/awCgm1SU ZaYWtwN3YL4/EXFhrcCtQ8A= =oV5E -----END PGP SIGNATURE-----
-- To strive, to seek, to find, and not to yield.
On 11 Jul 2007, at 02:04, Kieran Lal wrote:
Perhaps taking Johnathan up on his offer to support a mirror of D.O. to test this patch would be prudent.
But how would that work? Would it just a 2 week old copy of drupal.org with nodes and comments closed? That doesn't help me with patch reviewing.
http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser
Any chance that could get set up to run on a cron job and output somewhere regularly?
Maybe these logs periodically available (in an automated way) would be really useful. -- Dries Buytaert :: http://www.buytaert.net/
On 7/11/07, Dries Buytaert <dries@buytaert.net> wrote:
On 11 Jul 2007, at 02:04, Kieran Lal wrote:
Perhaps taking Johnathan up on his offer to support a mirror of D.O. to test this patch would be prudent.
But how would that work? Would it just a 2 week old copy of drupal.org with nodes and comments closed? That doesn't help me with patch reviewing.
I would assume you would want some bench marks. I assume you would also want to lots and lots of comments and nodes created. If there is any test we could do make a write happen against the slave we would want to do that. I would assume that could be captured in MySQL logging some how.
http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser
Any chance that could get set up to run on a cron job and output somewhere regularly?
Maybe these logs periodically available (in an automated way) would be really useful.
That's what I was hoping. We know several of the worst queries already and we don't have fixes, but having consistent reporting of the problem could allow us to continue to track down more advanced solutions. Cheers, Kieran --
Dries Buytaert :: http://www.buytaert.net/
-- To strive, to seek, to find, and not to yield.
On 10 Jul 2007, at 23:36, Gerhard Killesreiter wrote:
Dries, it is very nice to offer some of your not so copious spare time for this good cause. Sadly, there actually isn't that much you, I, or any OSUOSL outsider can do when it comes to our hardware and its setup.
After discussing your offer with Narayan, we agreed that it would be best if you do that what you can do best: review patches. Especially patches which would help our infrastructure.
OK.
The number one patch to review is David's master-slave patch at:
Yes, I figured that. I'll start by reviewing patches. People that want to help test this patch, or that want to put some programming effort into it, please let me know. Once I reviewed the patch, I'll follow-up with more details and a bit of an action plan. -- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dries Buytaert schrieb:
On 10 Jul 2007, at 23:36, Gerhard Killesreiter wrote:
Dries, it is very nice to offer some of your not so copious spare time for this good cause. Sadly, there actually isn't that much you, I, or any OSUOSL outsider can do when it comes to our hardware and its setup.
After discussing your offer with Narayan, we agreed that it would be best if you do that what you can do best: review patches. Especially patches which would help our infrastructure.
OK.
The number one patch to review is David's master-slave patch at:
Yes, I figured that. I'll start by reviewing patches. People that want
Thanks!
to help test this patch, or that want to put some programming effort into it, please let me know. Once I reviewed the patch, I'll follow-up with more details and a bit of an action plan.
Please include memcached in that action plan. We have now more memory for our webheads (not installed yet) and my intention was to use some of it for memcached if it proves to be viable. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlMwrfg6TFvELooQRApj/AJ49fH5U4v8RX8AEJlWmiM8Y+0vgLACfenL1 t+V+9YEMLZWPKLPGpK5DzCs= =K+vk -----END PGP SIGNATURE-----
participants (9)
-
Augustin (Beginner) -
David Strauss -
Dries Buytaert -
Dries Buytaert -
Gerhard Killesreiter -
Jeff Griffiths -
Jonathan Lambert -
Kieran Lal -
Vasileios Lourdas