Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #193234 > unrolled thread

Some tasks very slow after upgrade from Jessie to Stretch

Back to article view | Back to linux.debian.user

Contents

  Some tasks very slow after upgrade from Jessie to Stretch Schrey <debian-user@schreyben.de> - 2018-02-28 19:20 +0100
    Re: Some tasks very slow after upgrade from Jessie to Stretch Don Armstrong <don@debian.org> - 2018-02-28 20:10 +0100
    Re: Some tasks very slow after upgrade from Jessie to Stretch David Christensen <dpchrist@holgerdanske.com> - 2018-03-01 05:50 +0100
      Re: Some tasks very slow after upgrade from Jessie to Stretch deloptes <deloptes@gmail.com> - 2018-03-01 08:10 +0100
        Re: Some tasks very slow after upgrade from Jessie to Stretch Curt <curty@free.fr> - 2018-03-01 11:30 +0100
          Re: Some tasks very slow after upgrade from Jessie to Stretch Sven Hartge <sven@svenhartge.de> - 2018-03-01 13:10 +0100
      Re: Some tasks very slow after upgrade from Jessie to Stretch rhkramer@gmail.com - 2018-03-01 14:40 +0100

#193234 — Some tasks very slow after upgrade from Jessie to Stretch

Greetings.


Recently I cloned & upgraded a (virtual) build system, from Jessie to 
Stretch,
and some tasks have become so slow that it hurts.


Look at 'git archive' for example, the tar part:


bob@build-stretch:/stuff/git/linux-stable$

time git archive v3.18.95 | perf stat tar xC /usr/src/test

  Performance counter stats for 'tar xC /usr/src/test':

    125849.626176   task-clock (msec)        #   0.945 CPUs utilized
              984   context-switches         #   0.008 K/sec
                3   cpu-migrations           #   0.000 K/sec
              135   page-faults              #   0.001 K/sec
  474,044,657,252   cycles                   #   3.767 GHz
  190,146,876,098   stalled-cycles-frontend  #  40.11% frontend cycles idle
  122,803,944,538   stalled-cycles-backend   #  25.91% backend cycles idle
  511,500,080,424   instructions             #   1.08  insn per cycle
                                             #   0.37  stalled cycles 
per insn
   93,671,911,207   branches                 # 744.316 M/sec
    2,810,364,901   branch-misses            #   3.00% of all branches

    133.182776679 seconds time elapsed

real    2m13.234s
user    0m4.268s
sys     2m6.748s


bob@build-jessie:/stuff/git/linux-stable$

time git archive v3.18.95 | perf stat tar xC /usr/src/test

  Performance counter stats for 'tar xC /usr/src/test':

      3908.736041   task-clock (msec)        #   0.183 CPUs utilized
           44,396   context-switches         #   0.011 M/sec
              134   cpu-migrations           #   0.034 K/sec
              133   page-faults              #   0.034 K/sec
    9,065,881,286   cycles                   #   2.319 GHz
    7,497,944,714   stalled-cycles-frontend  #  82.71% frontend cycles idle
    6,277,695,339   stalled-cycles-backend   #  69.25% backend cycles idle
    2,987,957,839   instructions             #   0.33  insns per cycle
                                             #   2.51  stalled cycles 
per insn
      576,836,524   branches                 # 147.576 M/sec
       14,885,342   branch-misses            #   2.58% of all branches

     21.365168109 seconds time elapsed

real    0m21.426s
user    0m4.664s
sys     0m6.164s


A bit slower now, on Stretch.

(and why are the perf numbers vastly different I wonder?)


Same thing for 'rm -rf'ing a kernel build tree, on the Stretch VM
it's multiple times slower - takes approx. two minutes.


KVM, same host, storage is virtio block device in LVM.
Setup has been working flawless for years.
Host is also Debian. Still Wheezy, but for a reason.


I've already

- tried different kernels on host and guest
- switched to ext3 from ext4 on guest (a bit faster, but not much)
- used a local git repo in guest (vs. network share which is default)
- asked the Googol

but no remedies yet.



What am I missing?

Has anyone experienced similar things after
upgrading from Jessie to Stretch?



Regards
Ingmar

-- 
assembled from 100% recycled electrons

[toc] | [next] | [standalone]

#193236

On Wed, 28 Feb 2018, Schrey wrote:
> bob@build-stretch:/stuff/git/linux-stable$
[...]
> sys     2m6.748s
> bob@build-jessie:/stuff/git/linux-stable$

[...]
> sys     0m6.164s
[...]
> Has anyone experienced similar things after upgrading from Jessie to
> Stretch?

I haven't, but a little birdie makes me wonder if this is the
spectre/meltdown mitigation causing issues.

Does this issue recur if the jessie and stretch machines are running the
exact same kernel? Does this happen if you're running jessie/stretch on
bare hardware or a more recent KVM/kernel?


-- 
Don Armstrong                      https://www.donarmstrong.com

Le temps est un grand maître, dit-on; le malheur est qu'il soit un
maître inhumain qui tue ses élèves.
Time is a great teacher, but unfortunately it kills all its pupils.
 -- Hector Berlioz

[toc] | [prev] | [next] | [standalone]

#193243

On 02/28/18 10:11, Schrey wrote:
> Recently I cloned & upgraded a (virtual) build system, from Jessie to 
> Stretch,
> and some tasks have become so slow that it hurts.

I am a Debian user, not a Debian tester or a Debian developer.


I prefer Debian Stable because I want my computers to work reliably.  I 
typically delay major version upgrades for 6+ months, to allow Stable to 
stabilize.  I skipped Jesse entirely, and only recently upgraded to Stretch.


There are two schools of thought for Debian major version upgrades:

1.  Do an in-place upgrade.

2.  Do a fresh install and migrate.


Years ago, I tried the former.  Invariably, I ran into problems I could 
not trouble-shoot and ended up with systems that I had no confidence in. 
  Yours is just another in an unending stream of posts demonstrating 
that my experience was not unique, and still persists.  I can only 
conclude that an in-place upgrade of something as complex as a real, 
working, and productive Debian system is an exercise in futility.


So, now I do the latter.  This is facilitated by, and integrated into, 
my backup/ restore, archive, and imaging processes.  I have confidence 
in the results.


David

[toc] | [prev] | [next] | [standalone]

#193245

David Christensen wrote:

> So, now I do the latter.  This is facilitated by, and integrated into,
> my backup/ restore, archive, and imaging processes.  I have confidence
> in the results.

I have been updating regularly wheezy -> jessie -> stretch

I never experienced any problem

[toc] | [prev] | [next] | [standalone]

#193247

On 2018-03-01, deloptes <deloptes@gmail.com> wrote:
> David Christensen wrote:
>
>> So, now I do the latter.  This is facilitated by, and integrated into,
>> my backup/ restore, archive, and imaging processes.  I have confidence
>> in the results.
>
> I have been updating regularly wheezy -> jessie -> stretch
>
> I never experienced any problem
>
>

Me neither and what he posits as another data point in support of his
opinion, isn't.

-- 
“When fascism comes to America, it will be wrapped in the flag and
carrying the cross.” – Sinclair Lewis, 1935, "It Can't Happen Here"

[toc] | [prev] | [next] | [standalone]

#193249

Curt <curty@free.fr> wrote:
> On 2018-03-01, deloptes <deloptes@gmail.com> wrote:
>> David Christensen wrote:

>>> So, now I do the latter.  This is facilitated by, and integrated
>>> into, my backup/ restore, archive, and imaging processes.  I have
>>> confidence in the results.
>>
>> I have been updating regularly wheezy -> jessie -> stretch
>>
>> I never experienced any problem

> Me neither and what he posits as another data point in support of his
> opinion, isn't.

Debian in-place upgrades just work. My personal systems have been
upgraded and never reinstalled, even through several hardware up- and
sidegrades, since 1999. I also am very brave and run Unstable with daily
upgrades, so the in-place-upgrade routine is excercised very very often
on those systems.

And the systems I am responsible for at work are also mostly upgraded
and not reinstalled.

Of course the smoothness of the upgrade depends on the amount of
packages installed, the configuration of the packages and the system as
a whole.

In my experience things like upgrading Apache with many VHosts can be
quite painful and labor intensive if you don't use a templating system.
The change from Apache2.2 in Wheezy to Apache2.4 in Jessie is such a
case. 

Also if you bastardized the installation before and went against the way
the distribution does something, your experience during the upgrade will
be worse. But this is true for every Linux distribution, not Debian
alone.

So no, an in-place-upgrade is definately *not* an excercise in futility.
Only if you did something very wrong before this will be your
impression.

Grüße,
Sven

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#193250

On Wednesday, February 28, 2018 11:41:34 PM David Christensen wrote:

> There are two schools of thought for Debian major version upgrades:
> 
> 1.  Do an in-place upgrade.
> 
> 2.  Do a fresh install and migrate.
> 
> 
> Years ago, I tried the former.  Invariably, I ran into problems I could
> not trouble-shoot and ended up with systems that I had no confidence in.
>   Yours is just another in an unending stream of posts demonstrating
> that my experience was not unique, and still persists.  I can only
> conclude that an in-place upgrade of something as complex as a real,
> working, and productive Debian system is an exercise in futility.
> 
> 
> So, now I do the latter.  This is facilitated by, and integrated into,
> my backup/ restore, archive, and imaging processes.  I have confidence
> in the results.

+1

I'm not sure it's really an exercise in futility, but it is somewhat "scary".  
Several times I've read the upgrade notes (not sure of the right name) about 
the gotchas that you have to deal with before, during, and after the upgrade 
and decided that the hassle was just not worth it.

What I typically do is install the new OS to a new (at least new to me) 
computer and run it in parallel for some period of time until (1) I have 
confidence that everything works and until I've moved all my "real user files" 
(photos, videos, documents, ....) from the old to the new.

I then start to gather the parts for my next new computer by watching places 
like Newegg, TigerDirect, ebay, and sometimes yard sales, Craigslist, and 
similar for sales and bargains.

I used to be able to get the parts for a not completely state of the art 
computer for about $200, buying the case, power supply, RAM, and hard drive 
separately (but I often buy the CPU and motherboard as a combination).

I have noticed that I don't find sales quite as good, especially on RAM, 
motherboards and CPUs, so I expect my next computer might be closer to $300 or 
slightly more.

Another possibility is to buy a "refurbished" system (I'm not sure what 
"refurbishment" gets done maybe just a good (I hope) cleaning.

Now I have cases that I happy with in terms of side (mid to small size  
towers) so I no longer look for new cases--just empty the case and put new 
parts in.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web