headers
Joseph Bishay | 1 Apr 2010 03:29
Picon

Re: recommend a disk setup for LTSP install?

Hello,

On Tue, Mar 30, 2010 at 10:01 PM, David Burgess <apt.get@...> wrote:
> On Tue, Mar 30, 2010 at 5:58 PM, john <lists.john@...> wrote:
>> Are  SSD write times comparable with SAS? I wasn't aware of that. I'll
>> take a look.
> Basically, decent SSDs are faster than any spinning drive for
> sequential, and way, way faster for anything random, as seek times and
> latency are virtually eliminated. Terminal servers with lots of users
> can fall victim quickly to random reads and writes, the exact arena
> where SSDs really shine.
> db

I thought that the issue with solid state was their short life-span
with respect to writes on the media.  Is that no longer an issue?

Joseph

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
james | 1 Apr 2010 08:12
Favicon

Help: any developers

Hi
I installed ltsp from lynx (beta)
Much head scratching as it does not work ...
the kernel loads
the initrd loads
ndb loads on port 2000

Does this prompt any ideas:
...
eth0 configured ... looks ok ip, server, gw ...
Done
Begin: Mounting root file system... ...
Begin:  Running /scripts/nfs-top ...
Done
[ 3.371441] nbd0 Hangup
Negotiation: size.. 539052KB
bs=1024, sz=539052
unknown partition table
...

I do not know enough about squashfs to go on here

Thanks
James

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
(Continue reading)

Permalink | Reply | 0 comments |
headers
john | 1 Apr 2010 23:21
Picon

Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

Hi all,

As a follow up to my previous post. I did some testing and have come
to the conclusion that firefox is indeed at the heart of my problem
re: high I/O wait times. See below.

On Wed, Mar 31, 2010 at 6:39 PM, john <lists.john@...> wrote:

> Oh, heck, I'll throw out another thing :-)
>
> I was surprised to see that there was so much disk write activity. I
> am trying to figure out what is getting written where. I found a tool
> called IOTOP that should correlate disk i/o to particular apps.
> Unfortunately it uses some kernel hooks that aren't supported by
> Ubuntu kernels so i am in the process of compiling an ubuntu kernel
> with the proper stuff included.

So I compiled a custom kernel by copying my .config and following directions
here https://help.ubuntu.com/community/Kernel/Compile

I turned enabled I/O accounting so that I could use IOTOP
http://guichaz.free.fr/iotop/

CONFIG_TASK_IO_ACCOUNTING=y

compiled the kernel and rebooted.

IOTOP has a number of interesting features, including the ability to
show all processes, all threads, only active process/threads,
cumulative or real-time disk I/O etc. Running IOTOP while opening
(Continue reading)

Permalink | Reply | 20 comments |
headers
David Burgess | 1 Apr 2010 23:49
Picon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

On Thu, Apr 1, 2010 at 3:21 PM, john <lists.john@...> wrote:

> I'm still interested in folks ideas about the "fastest" approach to
> take re: disk writes, and especially ideas about taming firefox under
> LTSP.

I would think with browser cache disabled that number should go way
down. As to mitigating the effects of disk writes, nothing is faster
than a ramdisk, and a proper SSD (Intel, Indilinx, Sandforce
controllers) will put SAS to shame, particularly on random writes.

Also check your mount parameters. noatime should help if you're not
already using it. I believe jfs is your best format choice for small
files, and put the journal on a separate volume (most journaling
filesystems allow this).

You may also want to try different io schedulers. cfq is supposed to
be the most responsive but if the device is bogged you might have
better luck with anticipatory or deadline. noop is not likely to help
when you have a lot of writes happening. deadline is the best I've
found for SSDs, although some people like noop. I think noop would
work better with few writes happening on the device. You can set the
default scheduler in grub, 'elevator=noop' or per device in
/etc/rc.local 'echo anticipatory > /sys/block/sda/queue/scheduler'.

Hope that helps.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim McQuillan | 1 Apr 2010 23:37

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

John,

Try disabling the browser cache.  That should stop it from keeping 
copies of pages in users home directories.

If you do that, then you'll take a performance hit on your Internet 
connection, but that can be fixed by setting up a squid proxy.  At least 
that way,  the cached pages can be shared by ALL users instead of having 
separate copies of the pages for each user.

Jim McQuillan
jam@...

john wrote:
> Hi all,
> 
> As a follow up to my previous post. I did some testing and have come
> to the conclusion that firefox is indeed at the heart of my problem
> re: high I/O wait times. See below.
> 
> On Wed, Mar 31, 2010 at 6:39 PM, john <lists.john@...> wrote:
> 
>> Oh, heck, I'll throw out another thing :-)
>>
>> I was surprised to see that there was so much disk write activity. I
>> am trying to figure out what is getting written where. I found a tool
>> called IOTOP that should correlate disk i/o to particular apps.
>> Unfortunately it uses some kernel hooks that aren't supported by
>> Ubuntu kernels so i am in the process of compiling an ubuntu kernel
>> with the proper stuff included.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gavin McCullagh | 1 Apr 2010 23:59
Picon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

Hi,

On Thu, 01 Apr 2010, john wrote:

> In 10 minutes of futzing about firefox wrote 17.2 M to disk and read
> off 4K. All the writing apparently happens in the users ./mozilla
> directory. Indeed of the 47Gigs used on my disk 26Gigs (55%) are given
> over to my 570 users firefox profiles (eg ~45 M per user).

That's very interesting.

> I have followed
> https://help.ubuntu.com/community/UbuntuLTSP/Firefox3Optimize and I
> hope that it will make a difference. I am also going to mount /home on
> a separate disk either under raid 0 or 10 and/or perhaps buy a SAS or
> solid state disk. I am still mulling that one.

There are some more tricks here:

http://forums.mozillazine.org/viewtopic.php?f=7&t=696145&start=15&st=0&sk=t&sd=a

The Firefox guys are working on reducing disk IO:

https://wiki.mozilla.org/Firefox/Goals/2010Q1/IO_Reduction#Timeline_.2F_Milestones

> I'm still interested in folks ideas about the "fastest" approach to
> take re: disk writes, and especially ideas about taming firefox under
> LTSP.

I recall some time ago a guy who was running his .firefox directory on a
(Continue reading)

Permalink | Reply | 0 comments |
headers
R. Scott Belford | 2 Apr 2010 00:07
Favicon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

On Thu, Apr 1, 2010 at 11:37 AM, Jim McQuillan <jam <at> mcquil.com> wrote:
> John,
>
> Try disabling the browser cache.  That should stop it from keeping
> copies of pages in users home directories.
>
> If you do that, then you'll take a performance hit on your Internet
> connection, but that can be fixed by setting up a squid proxy.  At least
> that way,  the cached pages can be shared by ALL users instead of having
> separate copies of the pages for each user.

+1. This is the only way I've been able to deal with fat/thin clients
and Firefox. What I wonder is if there is a tradeoff between only a
few MB of cache versus 0. I have not tested this. Having /home on a
different array or disk helps some. When possible I just try and steer
people to another browser.

>
> Jim McQuillan
> jam <at> Ltsp.org
>
>
> john wrote:
>> Hi all,
>>
>> As a follow up to my previous post. I did some testing and have come
>> to the conclusion that firefox is indeed at the heart of my problem
>> re: high I/O wait times. See below.
>>
>> On Wed, Mar 31, 2010 at 6:39 PM, john <lists.john <at> gmail.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
R. Scott Belford | 2 Apr 2010 00:35
Favicon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

On Thu, Apr 1, 2010 at 11:21 AM, john <lists.john <at> gmail.com> wrote:
> Hi all,
>
> As a follow up to my previous post. I did some testing and have come
> to the conclusion that firefox is indeed at the heart of my problem
> re: high I/O wait times. See below.
>
> On Wed, Mar 31, 2010 at 6:39 PM, john <lists.john <at> gmail.com> wrote:
>
>> Oh, heck, I'll throw out another thing :-)
>>
>> I was surprised to see that there was so much disk write activity. I
>> am trying to figure out what is getting written where. I found a tool
>> called IOTOP that should correlate disk i/o to particular apps.
>> Unfortunately it uses some kernel hooks that aren't supported by
>> Ubuntu kernels so i am in the process of compiling an ubuntu kernel
>> with the proper stuff included.
>
> So I compiled a custom kernel by copying my .config and following directions
> here https://help.ubuntu.com/community/Kernel/Compile
>
> I turned enabled I/O accounting so that I could use IOTOP
> http://guichaz.free.fr/iotop/
>
> CONFIG_TASK_IO_ACCOUNTING=y
>
> compiled the kernel and rebooted.
>
> IOTOP has a number of interesting features, including the ability to
> show all processes, all threads, only active process/threads,
(Continue reading)

Permalink | Reply | 0 comments |
headers
john | 2 Apr 2010 01:41
Picon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

On Thu, Apr 1, 2010 at 2:49 PM, David Burgess <apt.get@...> wrote:
> On Thu, Apr 1, 2010 at 3:21 PM, john <lists.john@...> wrote:
>
>> I'm still interested in folks ideas about the "fastest" approach to
>> take re: disk writes, and especially ideas about taming firefox under
>> LTSP.
>
> I would think with browser cache disabled that number should go way
> down. As to mitigating the effects of disk writes, nothing is faster
> than a ramdisk, and a proper SSD (Intel, Indilinx, Sandforce
> controllers) will put SAS to shame, particularly on random writes.
>
> Also check your mount parameters. noatime should help if you're not
> already using it. I believe jfs is your best format choice for small
> files, and put the journal on a separate volume (most journaling
> filesystems allow this).
>
> You may also want to try different io schedulers. cfq is supposed to
> be the most responsive but if the device is bogged you might have
> better luck with anticipatory or deadline. noop is not likely to help
> when you have a lot of writes happening. deadline is the best I've
> found for SSDs, although some people like noop. I think noop would
> work better with few writes happening on the device. You can set the
> default scheduler in grub, 'elevator=noop' or per device in
> /etc/rc.local 'echo anticipatory > /sys/block/sda/queue/scheduler'.
>
> Hope that helps.

Thanks for the advice. It is helpful!
(Continue reading)

Permalink | Reply | 0 comments |
headers
john | 2 Apr 2010 01:42
Picon

Re: Firefox is indeed the high disk IO culprit was Re: recommend a disk setup for LTSP install?

On Thu, Apr 1, 2010 at 2:37 PM, Jim McQuillan <jam@...> wrote:
> John,
>
> Try disabling the browser cache.  That should stop it from keeping
> copies of pages in users home directories.
>
> If you do that, then you'll take a performance hit on your Internet
> connection, but that can be fixed by setting up a squid proxy.  At least
> that way,  the cached pages can be shared by ALL users instead of having
> separate copies of the pages for each user.
>
> Jim McQuillan
> jam@...
>

Hi Jim,

I did as of today. I'll watch SQUID on the firewall and see if I need
to add some ram.

Thanks for the help!

John

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
(Continue reading)

Permalink | Reply | 1 comment |

Gmane