[Server-devel] Server performance feedback and testing suggestions

David Leeming david at leeming-consulting.com
Sun Aug 1 18:20:29 EDT 2010


Some feedback inserted

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.

Will be posting up details on wiki pages when I get a chance. But we are
using Sundaya S4 kist with the 55W panels doubled up with 2A loads or less.
The units are self contained, well priced, and the system is modular so that
if one part goes down due to low voltage it doesn't pull the rest. So far we
have seen the unit with the server (1.5A load) running all night reaching
full charge by 11am even on a cloudy day. The 12V DC digital timers were
sourced from Rainbow Power, www.rpc.com.au)

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

OK, well we have set it up to run 24/7 with the timer override, allowing
teachers to set the timer to auto if need be (but then they will have the
daily task of manually switching it on, that can get neglected in my
experience, especially as the servers are in locked rooms, with the daily
hassle of finding keys etc. Sounds a minor issue but in practice it is best
to have the system as automated as possible).

We also added a line to the cron table (crontab -e) to have a daily reboot
just because we have been brought up to think that is a good thing!!!

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


We reconfigured with smaller groups (less than 35 per group) and it tested
OK - 6 class groups all independently collaborating and isolated from each
other. As it was the last day and Sunday, we could only do a limited test
with 5 XOs per class but we had Chat running with pretty good responsiveness
(the icon appearing in a few seconds on all laptops) on each of the 6
classes. Whilst this was happening I measured memory use as 184KB total
using ps_mem.py up from 170KB with no XOs active. We'll have to wait for a
monitoring visit to get the data on the full load situation. We only had 2
weeks to do all the training and obviously focused on laptop use and
classroom integration / the pedagogical side, although one teacher was
trained to do basic user management on Moodle. These teachers have mostly NO
previous computing experience. 

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

Yes was updated. Now works OK (at least based on the reduced load test
described above)

> 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





More information about the Server-devel mailing list