Project

General

Profile

Bug #4736

“zpool history” is consuming 100% CPU

Added by Marco . almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Xin Li
Category:
Middleware
Target version:
Start date:
04/06/2014
Due date:
% Done:

0%

Severity:
Backlog Priority:
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Hardware Configuration:
ChangeLog Required:
No
QA Status:
Not Tested

Description

The zpool history command does not finish and consumes 100% CPU on my system. This call is used by the scrubbing code which parses its output.

[root@freenas] /mnt/tank# ps aux | grep zpool
root        2279 100.0  0.0  1704772  2156 ??  R    1:15AM  817:53.33 zpool history tank
root        2280  0.0  0.0    16272  1424 ??  I    1:15AM    0:00.00 egrep ^[0-9\\.\\:\\-]{19} zpool scrub tank$
root      39364  0.0  0.0    16272  1952  0  S+    3:10PM    0:00.00 grep zpool

I can't reproduce it on every system. On most systems zpool history returns within a few seconds. On this particular pool, however, it does not. See this forum thread:

http://forums.freenas.org/index.php?threads/%E2%80%9Czpool-history%E2%80%9D-is-consuming-100-cpu.19997/

The behaviour I expect is that zpool history returns within a few seconds and does not consume significant CPU.

G2020
32GiB ECC RAM
2 mirrored vdevs

Screenshot from 2014-04-06 15_08_42.png (81.5 KB) Screenshot from 2014-04-06 15_08_42.png CPU graph Marco ., 04/06/2014 01:48 PM
procstat.gz (10.3 KB) procstat.gz procstat output Marco ., 04/07/2014 11:41 PM
707

Associated revisions

Revision b447e042 (diff)
Added by Xin Li almost 4 years ago

Work around the case where hisory buffer is larger than HIS_BUF_LEN (128K).

Ticket: #4736

Revision b447e042 (diff)
Added by Xin Li almost 4 years ago

Work around the case where hisory buffer is larger than HIS_BUF_LEN (128K).

Ticket: #4736

Revision 887098ca (diff)
Added by Xin Li almost 4 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

Revision 887098ca (diff)
Added by Xin Li almost 4 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

Revision de042548 (diff)
Added by Xin Li almost 4 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736
(cherry picked from commit 887098cab7b481404f44107ec9fac6e0a65d4ade)

Revision de042548 (diff)
Added by Xin Li almost 4 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736
(cherry picked from commit 887098cab7b481404f44107ec9fac6e0a65d4ade)

Revision a72a13f2 (diff)
Added by Xin Li over 3 years ago

Work around the case where hisory buffer is larger than HIS_BUF_LEN (128K).

Ticket: #4736

Revision a72a13f2 (diff)
Added by Xin Li over 3 years ago

Work around the case where hisory buffer is larger than HIS_BUF_LEN (128K).

Ticket: #4736

Revision d601e16c (diff)
Added by Xin Li over 3 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

Revision d601e16c (diff)
Added by Xin Li over 3 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

Revision ece4ce02 (diff)
Added by Xin Li over 3 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

Revision ece4ce02 (diff)
Added by Xin Li over 3 years ago

Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).

PR: bin/186574
Submitted by: Andrew Childs <lorne cons org nz> (with changes)
MFC after: 2 weeks

(cherry picked from commit 78e547c5404320fbd04ad333c9f9691a30b0e86e)

Ticket: #4736

History

#1 Updated by Jordan Hubbard almost 4 years ago

  • Assignee set to Xin Li
  • Target version set to 79

#2 Updated by Xin Li almost 4 years ago

Please provide 'procstat -kk -a' output.

#3 Updated by Xin Li almost 4 years ago

  • Status changed from Unscreened to Screened

#4 Updated by Marco . almost 4 years ago

Here's the “procstat -kk -a” output.

#5 Updated by Xin Li almost 4 years ago

  • Status changed from Screened to Resolved

This should have been resolved in trunk.

#6 Updated by Jordan Hubbard almost 4 years ago

  • Target version changed from 79 to 9.2.1.4-RELEASE

Also available in: Atom PDF