[Server-devel] Server performance feedback and testing suggestions

[Martin Langhoff]

David,

quick comments as you have short time over there.

On Fri, Jul 30, 2010 at 5:31 PM, David Leeming
<david at leeming-consulting.com> wrote:
> -  One "eBox" fanless VIA server with 1GB RAM (non-expandable). We had
> planned two (one for G3-4 and one for G5+) but vital eqt did not show up in
> time so we are managing with one.

One server should be ok

> -  Campus wide wireless network, solar powered, using a ratio of less than
> 30 XOs per AP.

Super!


> Layout is 3 x single storey double classrooms (G3A, 3B... 4A, 4B...etc) in
> line, separated by about 15m. The server is situated in a parallel line of
> classrooms about 6m to one side. We use some centrally located solar power
> supplies with POE. The whole system is DC powered and we use digital; timers
> to turn things off when not needed to save power. However the system
> provides good access for at least 15 hrs per day.

Great idea on the digital timers -- when you have a chance,
documenting the setup would benefit other deployments.

> (Advice on power management): I would like suggestions how the server can be
> safely turned on and off automatically.

I have designed the server so that it survives sanely hard power off.
During development and testing I almost never issue a formal shutdown.
Removing the powercord is de rigueur.

Just don't do it during yum / rpm updates (how I wish those were saner!)

OTOH, given that you have set timers, if everything is running smooth
you know what time power will be off, so you can set a cronjob at a
regular time to run shutdown. (As various clocks drift, this won't be
particularly reliable...)

Daily reboot _not_ needed.

> ... generally the
> impression was that networking was functioning well over the entire campus.

Excellent!

> However, we noticed that collaboration was not working well. XOs could not
> see all members of their course in neighbourhood view – it seemed to be

I would have expected that. The ejabberd server (if you've updated the
RPMs to the latest from olpcxs-testing) will handle many XOs well, but
the neighbourhood view on the XO doesn't cope well with so many XOs.

The cure: segregate presence by course (see xs techniques and
configuration in the wiki for the steps).

> This contrasts with the good responsive and reliable browsing. In this test,
> we were using presence service split by course, with the students added as
> “students” and the teachers of those grades added as “teachers”. No-one was

Hmmm, so even with segregated presence service you are seeing "slow"
presence issues. Can you confirm yum --enablerepo=olpcxs-testing
update doesn't bring a new version of ejabberd?

> given site roles. The teachers were also members of another course
> “teachers” intended to allow collaboration between the teachers in different
> grades.

That's best practice -- good.

> We would like some feedback on what could be the issue.

Very unlikely to be a problem on your end. An ejabberd bug or
ejabberd-moodle interaction issue could be what's happening.

If you want to make double sure that it's not memory, grab ps_mem.py
and run it http://www.pixelbeat.org/scripts/ps_mem.py -- post the
results.

top (or even better, the output of sar) will confirm that it's not cpu
or memory.

As for logs, the ejabberd logs are where it's at. And you can ask the
ejabberdctl tool a few things when users or shared sessions are not
appearing.

Can you boil down the problem to a set of steps that repro?

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff