Re: New machine for shitbox / wiki system
Hello! On Sat, Jul 05, 2008 at 02:16:41AM +0200, [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2008 at 10:56:17PM -0400, Barry deFreese wrote: I'm still a little concerned about the HD but I'm not sure how much trouble it would be to get it up on a new one. I'm up for suggestions, etc. Shouldn't be a problem I think... Just copy the whole disk :-) ... using dd. After doing that, you can use resize2fs to enlarge the file system to the new partiton's size. (Supposing that it is to be enlarged and not shrinked.) I also have a nicer machine P4 (2.4Ghz or so I think) that I was thinking about replacing flubber with but I am wondering if that makes the most sense? Since flubber is now the wiki code and such, should it be taken out of the more public role? I'm thinking maybe using the gnubber hardware for flubber and set up a new gnubber might make more sense. flubber is ``only'' acting as the main wiki (Git) repository server. And this functionality is supposed to be moved to the GNU Savannah machine. (If someone wants to help working on that, please shout.) flubber's speed should not be the cause for the wiki system slowness. Well, I'm always feeling a bit strange about the fact that a public machine prone to frequent crashes is also used for the wiki... That's why I put a note onto the wiki page about that. On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Rebuilding wiki pages is resource intensive w.r.t. raw CPU time, plus a bunch of spawning-a-lot-of-new-processes overhead. A faster machine should help there. Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Yes. That's also what I'd suggest. There'd as well be the plus of other people being able to reboot/recover hung systems, if Barry is on vacations, etc. Samuel, perhaps you can help to set-up such a system? (Remembering that you've just been doing the same for the Debian GNU/Hurd buildds.) Regards, Thomas signature.asc Description: Digital signature
Re: New machine for shitbox
Hello! On Sat, Jul 05, 2008 at 12:57:27PM +0100, Samuel Thibault wrote: Dani Doni, le Sat 05 Jul 2008 13:52:07 +0200, a écrit : Maybe I am wrong, but updates on wiki content should trigger little bursts of activity, not sustained periods of 100% cpu load. The wiki engine regenerates all the pages, that's what takes time. As I said before: it regenerates only those that need to be regenerated. Regards, Thomas signature.asc Description: Digital signature
Re: New machine for shitbox / wiki system
Thomas Schwinge, le Tue 08 Jul 2008 09:41:20 +0200, a écrit : Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Yes. That's also what I'd suggest. There'd as well be the plus of other people being able to reboot/recover hung systems, if Barry is on vacations, etc. Samuel, perhaps you can help to set-up such a system? Sure, the hard part is just a matter of having a working Debian system on it, install the packages from http://youpibouh.thefreecat.org/hurd-xen and a xen-hypervisor-something-nonpae package, update-grub, reboot with that, and give me ssh access. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New machine for shitbox / wiki system
Barry deFreese, le Tue 08 Jul 2008 12:28:57 -0400, a écrit : By working Debian system do you mean Debian GNU/Linux or a Debian Hurd system? A GNU/Linux system, since gnumach does not support running as dom0. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New machine for shitbox
On 7/5/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Maybe using web caching software like memcached[1] can help minimize disk access, as wiki content could be served from memory and only updates would hit the database triggering a cache update. In a such configuration, an alternate VM dedicated to serve wiki pages would/should consume very little resources. [1] http://www.danga.com/memcached/ -- Dani Doni -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New machine for shitbox
Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit : On 7/5/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Maybe using web caching software like memcached[1] can help minimize disk access, as wiki content could be served from memory and only updates would hit the database triggering a cache update. The problem is _not_ serving, it is updating. If the cpu is 100% busy during updates, then that's the cpu which is too slow, not the disk. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New machine for shitbox
On 7/5/08, Samuel Thibault [EMAIL PROTECTED] wrote: Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit : On 7/5/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Maybe using web caching software like memcached[1] can help minimize disk access, as wiki content could be served from memory and only updates would hit the database triggering a cache update. The problem is _not_ serving, it is updating. If the cpu is 100% busy during updates, then that's the cpu which is too slow, not the disk. Maybe I am wrong, but updates on wiki content should trigger little bursts of activity, not sustained periods of 100% cpu load. Those bursts IMHO are pretty acceptable. Don't you think? -- Dani Doni
Re: New machine for shitbox
Dani Doni, le Sat 05 Jul 2008 13:52:07 +0200, a écrit : On 7/5/08, Samuel Thibault [EMAIL PROTECTED] wrote: Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit : On 7/5/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Maybe using web caching software like memcached[1] can help minimize disk access, as wiki content could be served from memory and only updates would hit the database triggering a cache update. The problem is _not_ serving, it is updating. If the cpu is 100% busy during updates, then that's the cpu which is too slow, not the disk. Maybe I am wrong, but updates on wiki content should trigger little bursts of activity, not sustained periods of 100% cpu load. The wiki engine regenerates all the pages, that's what takes time. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New machine for shitbox
On 7/5/08, Samuel Thibault [EMAIL PROTECTED] wrote: Dani Doni, le Sat 05 Jul 2008 13:52:07 +0200, a écrit : On 7/5/08, Samuel Thibault [EMAIL PROTECTED] wrote: Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit : On 7/5/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) Maybe using web caching software like memcached[1] can help minimize disk access, as wiki content could be served from memory and only updates would hit the database triggering a cache update. The problem is _not_ serving, it is updating. If the cpu is 100% busy during updates, then that's the cpu which is too slow, not the disk. Maybe I am wrong, but updates on wiki content should trigger little bursts of activity, not sustained periods of 100% cpu load. The wiki engine regenerates all the pages, that's what takes time. Oh... ok, I see... -- Dani Doni
Re: New machine for shitbox
Hi, On Thu, Jul 03, 2008 at 10:56:17PM -0400, Barry deFreese wrote: I'm still a little concerned about the HD but I'm not sure how much trouble it would be to get it up on a new one. I'm up for suggestions, etc. Shouldn't be a problem I think... Just copy the whole disk :-) I also have a nicer machine P4 (2.4Ghz or so I think) that I was thinking about replacing flubber with but I am wondering if that makes the most sense? Since flubber is now the wiki code and such, should it be taken out of the more public role? I'm thinking maybe using the gnubber hardware for flubber and set up a new gnubber might make more sense. Well, I'm always feeling a bit strange about the fact that a public machine prone to frequent crashes is also used for the wiki... On the other hand, the wiki seems to need a fast machine, so using it for the wiki exclusively would be a waste... Not sure what the best approach is. Ideally, they should run in two distinct VMs sharing the hardware :-) -antrik- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New machine for shitbox
Hi folks, OK, I have finally put a new machine in for shitbox. It's still not super high-end (700Mhz PIII with 384Mb) but it should at least be more stable and come back up when rebooting. I also did a dist-upgrade. I hope that wasn't a bad thing. I'm still a little concerned about the HD but I'm not sure how much trouble it would be to get it up on a new one. I'm up for suggestions, etc. I also have a nicer machine P4 (2.4Ghz or so I think) that I was thinking about replacing flubber with but I am wondering if that makes the most sense? Since flubber is now the wiki code and such, should it be taken out of the more public role? I'm thinking maybe using the gnubber hardware for flubber and set up a new gnubber might make more sense. Thoughts? Thanks! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
