Help! Process scheduling issue
- Anmelden oder Registrieren um Kommentare zu schreiben
I've been using Debian for long time on my home server. Even when some daemon
did heavy computation or I did a `cp` of a huge file, and desktop remained
responsive. Since the servers I run here occasionally use high CPU (like I2P
and Tor) it's very important.
Since I moved to Trisquel 7, every time it happens, the entire desktop becomes
unresponsive for several minutes. Today it came to the point it happens every 5
minutes. Then things like X / window manager crash, suddenly the network
disconnects, keyboard and mouse hardly respond or not at all, windows
contents change to plain gray...
I don't know much about kernel configuration, preemption or scheduling, but it
looks like some issue with the way processes are given CPU time slots. A CPU
intensive process gets all the slots and nothing else works properly, i.e.
resource starving (X has no chance to get keyboard/mouse events and so on).
Can anything be done about it? How do I debug this? I'm really glad I moved to
Trisquel but this issue is a serious problem. Even if this were just a server
without GUI, the I2P daemon taking the CPU means that other daemons like ssh
and lighttpd stop responding to client requests.
Thanks in advance! Any help appreciated!!!
-- fr33domlover
Were the desktop environments the same?
Looks like Trisquel 7 comes with low latency and BFQ scheduler kernel patches. Those probably make very little sense on a server. Perhaps try another kernel, e.g. from http://www.jxself.org/linux-libre/
I'm not sure about jxself's config but I don't think it has either. Or if you feel like it, roll your own.
On 2014-12-02
name at domain wrote:
> Looks like Trisquel 7 comes with low latency and BFQ scheduler kernel
> patches. Those probably make very little sense on a server. Perhaps try
> another kernel, e.g. from http://www.jxself.org/linux-libre/
>
> I'm not sure about jxself's config but I don't think it has either. Or if
> you feel like it, roll your own.
I don't know enogh or have time to make my own kernels, but I can try
linux-libre. Why does Trisquel not use Linux Libre by default? Isn't it easier
than deblobbing Ubuntu's kernel which is probably full of proprietary garbage?
Also, I'm curious what "doesn't make sense for a server" means - in what sense
can something as low level as a kernel be better for a server or better for a
desktop?
Anyway I'll give Linux Libre a try. The website says it's supposed on
Trisquel :)
"Why does Trisquel not use Linux Libre by default?"
In a way, it does. It uses a modified version of the Linux-libre deblobbing scripts (those which are used to remove blobs from the kernel from kernle.org) to also catch the modifications done in Ubuntu-land.
"Isn't it easier than deblobbing Ubuntu's kernel which is probably full of proprietary garbage?"
It might be, but the difference in work is not much - It's not like every kernel update need to be re-deblobbed from scratch. Rather, it's typically a one-time update of the deblobbing script for major kernel releases and it generally continues working just fine from then forward until the next major release. In addition to it not being a big difference, not using the kernel from Ubuntu would also mean that Trisquel doesn't get Ubuntu's other (free) kernel patches and wouldn't get Ubuntu's security updates. These LTS releases of Trisquel are supported for five years, and most kernels are no longer supported by kernel.org during that time so Ubuntu's kernel team manages it. So using Ubuntu's kernel is really the best choice.
Is the clean linux-libre kernel better for servers than trisquel's in terms of
throughput vs performance? Will running a harddisk backup with duplicity freeze
and OS for several hours (like Trisquel's kernel does for me) or will it keep
everything usable (like I had it on Debian)?
On 2014-12-03
name at domain wrote:
> "Why does Trisquel not use Linux Libre by default?"
>
> In a way, it does. It uses a modified version of the Linux-libre deblobbing
> scripts (those which are used to remove blobs from the kernel from
> kernle.org) to also catch the modifications done in Ubuntu-land.
>
> "Isn't it easier than deblobbing Ubuntu's kernel which is probably full of
> proprietary garbage?"
>
> It might be, but the difference in work is not much - It's not like every
> kernel update need to be re-deblobbed from scratch. Rather, it's typically a
> one-time update of the deblobbing script for major kernel releases and it
> generally continues working just fine from then forward until the next major
> release. In addition to it not being a big difference, not using the kernel
> from Ubuntu would also mean that Trisquel doesn't get Ubuntu's other (free)
> kernel patches and wouldn't get Ubuntu's security updates. These LTS
> releases of Trisquel are supported for five years, and most kernels are no
> longer supported by kernel.org during that time so Ubuntu's kernel team
> manages it. So using Ubuntu's kernel is really the best choice.
I should point out that you can get the normal kernel from Trisquel's normal repositories through the linux-generic package (the kernel installed by default is linux-lowlatency).
- Anmelden oder Registrieren um Kommentare zu schreiben