[OpenIndiana-discuss] Shell to use?

Joshua M. Clulow josh at sysmgr.org
Tue Jan 19 04:54:00 UTC 2021


On Mon, 18 Jan 2021 at 20:27, Hung Nguyen Gia via openindiana-discuss
<openindiana-discuss at openindiana.org> wrote:
> OI included many shells. So far I only stick with the default, bash.
> But the performance is very bad. e.g: when using pkgsrc to build packages.
>
> As I have said on this list: pkgsrc bootstrap on OI is 4x slower than on FreeBSD. Building packages also that slower.
>
> I think the problem is of the shell. Because I see it checking for something very slowly.
>
> The output printed on the screen 'Checking for...' is line by line, very slow. Meanwhile, the same thing on FreeBSD is blazing fast that I can't even see what's going on at all.
>
> I'm thinking about using other shell than bash.
>
> But I can't test with each shell. They are too many.
>
> From your own experience, which shell is the fastest?

I think you're making some big assumptions about what's going on here.
It feels like it would be a better idea to characterise the workload
that you feel is not running well enough.

You can run the pkgsrc bootstrap over and over again, on demand, so
that seems a pretty easy workload to look at first.  I would start by
trying to see if there is an obvious bottleneck; e.g., does "mpstat 1
1" show you that all of the CPUs are 100% busy all of the time?  If
they are not, maybe look to see what's happening with respect to I/O;
e.g., "iostat -xn 1" might show high latency or utilisation during the
build.

There are a _lot_ of variables to investigate when comparing two OSes.
Are you using ZFS root for FreeBSD as well as for OpenIndiana?  Is the
pkgsrc bootstrap spawning more or less processes in parallel on each
system?

A lot of "configure" scripts tend to spawn a large number of
processes.  Perhaps our fork() is more expensive than FreeBSD fork().
You could investigate the rate and quantity of new processes created,
the latency of various system calls with DTrace, etc.  If a lot of CPU
time is being spent in the kernel, you could use DTrace to profile
stacks and render them as a Flamegraph to see if there is an obvious
bottleneck.

One could even imagine a scenario where the speed of the build is
constrained by pipe buffer performance between the bootstrap program
and the SSH daemon on the system, or the graphical console.  If you
redirect the build output to /dev/null or to a tmpfs file, does the
build run any faster?

At any rate, lots to explore.  I would start by looking at what the
computer is actually doing, rather than exploring replacement shells.
Once you get some preliminary results, I am sure folks will be
interested in your findings.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org



More information about the openindiana-discuss mailing list