New machine for shitbox

[Barry deFreese]

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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[olafBuddenhagen]

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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Dani Doni]

On 7/5/08, olafBuddenhagen@... <olafBuddenhagen@...> 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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault]

Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit :

> On 7/5/08, olafBuddenhagen@... <olafBuddenhagen@...> 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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Dani Doni]

On 7/5/08, Samuel Thibault <samuel.thibault@...> wrote:

> Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit :
>
> > On 7/5/08, olafBuddenhagen@... <olafBuddenhagen@...> 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

[Samuel Thibault]

Dani Doni, le Sat 05 Jul 2008 13:52:07 +0200, a écrit :

> On 7/5/08, Samuel Thibault <samuel.thibault@...> wrote:
> > Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit :
> >
> > > On 7/5/08, olafBuddenhagen@... <olafBuddenhagen@...> 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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Dani Doni]

On 7/5/08, Samuel Thibault <samuel.thibault@...> wrote:

> Dani Doni, le Sat 05 Jul 2008 13:52:07 +0200, a écrit :
>
> > On 7/5/08, Samuel Thibault <samuel.thibault@...> wrote:
>  > > Dani Doni, le Sat 05 Jul 2008 13:21:29 +0200, a écrit :
>  > >
>  > > > On 7/5/08, olafBuddenhagen@... <olafBuddenhagen@...> 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

[Thomas Schwinge-6]

Hello!

On Sat, Jul 05, 2008 at 02:16:41AM +0200, olafBuddenhagen@... 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

[Thomas Schwinge-6]

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

[Samuel Thibault]

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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Barry deFreese]

Samuel Thibault wrote:

> 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
>
>  

Samuel,

By "working Debian system" do you mean Debian GNU/Linux or a Debian Hurd
system?

Thanks,

Barry deFreese


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault]

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 debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...