Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: Why is my hexacore Xeon at 100% for copying some files via samba?

  1. #11
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,679
    Blog Entries
    15

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by suse_rasputin View Post
    Ok in one terminal I have:

    Code:
     journalctl -f
    Hint: You are currently not seeing messages from other users and the system.
          Users in the 'systemd-journal' group can see all messages. Pass -q to
          turn off this notice.
    -- Logs begin at Sun 2020-07-26 17:31:35 CEST. --
    Sep 30 17:45:11 dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:11 dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:11 dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:14 dell6 plasmashell[2965]: file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/BusyIndicatorStyle.qml:26:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:45:14 dell6 systemd[2475]: Started app-org.kde.konsole-b10ed26cdaac41b7a4d5a039c9fe73c5.scope.
    Sep 30 17:45:14  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:17  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:17  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:20  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:20  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:23  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:26  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:29  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:35  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:44  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:47  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:47  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:50  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:53  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:53  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:56  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:45:59  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:02  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:05  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:11  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:11  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:14  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:14  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:17  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:20  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:23  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:29  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:32  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:35  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:36  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:36  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:36  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:36  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:37  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:37  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:37  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:37  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:37  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:38  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:38  dell6 plasmashell[2965]: qml: temp unit: 0
    Sep 30 17:46:39  dell6 plasmashell[2965]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
    Sep 30 17:46:41  dell6 plasmashell[2965]: qml: temp unit: 0

    while in the other

    Code:
    dell6:~ # echo 1 > /proc/sysrq-trigger
    dell6:~ # echo 1 > /proc/sysrq-trigger
    dell6:~ # echo 1 > /proc/sysrq-trigger
    dell6:~ # echo 1 > /proc/sysrq-trigger
    dell6:~ #
    Hi
    Have you reconfigured the logging?

    I see the likes of;

    Code:
    [229515.002898] sysrq: Show backtrace of all active CPUs
    [229515.002904] NMI backtrace for cpu 3
    [229515.002908] CPU: 3 PID: 28735 Comm: bash Tainted: P        W  OE     5.8.10-1-default #1 openSUSE Tumbleweed
    [229515.002909] Hardware name: Canyon/, BIOS MKQ7710H.86A.0074.2018.1025.1727 10/25/2018
    [229515.002911] Call Trace:
    [229515.002924]  dump_stack+0x6b/0x88
    [229515.002930]  ? lapic_can_unplug_cpu.cold+0x3e/0x3e
    [229515.002933]  nmi_cpu_backtrace.cold+0x14/0x52
    [229515.002936]  nmi_trigger_cpumask_backtrace+0xf6/0xf8
    [229515.002941]  __handle_sysrq.cold+0x43/0x110
    [229515.002944]  write_sysrq_trigger+0x24/0x32
    [229515.002948]  proc_reg_write+0x51/0x90
    [229515.002951]  vfs_write+0xc7/0x1f0
    [229515.002954]  ksys_write+0x5f/0xe0
    [229515.002958]  do_syscall_64+0x4d/0xd0
    [229515.002963]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [229515.002967] RIP: 0033:0x7f4530938a93
    [229515.002970] Code: 8b 15 01 f4 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
    [229515.002971] RSP: 002b:00007ffc851a5928 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [229515.002973] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f4530938a93
    [229515.002974] RDX: 0000000000000002 RSI: 00005590703b55a0 RDI: 0000000000000001
    [229515.002975] RBP: 00005590703b55a0 R08: 000000000000000a R09: 0000000000000000
    [229515.002977] R10: 000055906e94361a R11: 0000000000000246 R12: 0000000000000002
    [229515.002978] R13: 00007f4530a09500 R14: 0000000000000002 R15: 00007f4530a09700
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  2. #12
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,735
    Blog Entries
    2

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Your iotop unsurprisingly says that 100% of of your CPU is allocated to writing, and more specifically to your sda2 (likely where you mounted your network share).

    One really fundamental principle you have to know in the first place is that
    Reads involve almost no load. All you're doing is detecting data on the disk and storing a copy usually in memory and assembling the pieces together to be the original file.
    Writes on the other hand are processing intensive, but not always CPU intensive. Better disk firmware will do most of the work in silicon both in the disk and on your systemboard. Writes are complex, the disk likely will have pre-allocated or on demand different sizes of sequential blocks (may be related to disk fragmentation), the file to be written is broken up into typically 256k blocks and depending on the disk technology placed in the disk storage in an organized way. There may be related functions to ensure data integrity.

    There will likely be additional functions involved related to the type of file transfer over remote and network connections.

    What this means is that
    Unsurprisingly your source (original location of your files) has no load because you're just reading from disk which is always an insignificant load.
    Your TW machine appears to be performing all the work writing to the remote disk, the machine where the disk is located hardly has to do anything. This is a bit surprising to me but probably can be explained easily... When a file is written, a number of things have to happen of which some will be handled by your disk controller firmwares in your disk and on your systemboard, but some will be handled by your operating system... primarily the collection of the file file pieces, aggregating and piecing into blocks of appropriate size for transfer, and performing whatever other functions are supported by the operation... I haven't looked closely at the SMB protocol, but assume that integrity functions are performed like checksums, and perhaps even supports atomicity, which means that the transfers of each chunk of data has to be successful else the entire operation is cancelled and rolled back. Files being transferred may also be temporarily stored as temporary files until the entire transfer is completed and its integrity verified before finally copied to its final destination... All of which requires more calculations and more writes (plus deletes).

    What I'm saying is that file transfers aren't necessarily simple operations, and there may be a lot happening under the hood.
    To fully understand all this, you'd probably want to read some documentation about the file systems involved, the SMB protocol being used at the Developer level.

    HTH,
    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  3. #13

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Have you reconfigured the logging?

    I see the likes of;

    Code:
    [229515.002898] sysrq: Show backtrace of all active CPUs
    [229515.002904] NMI backtrace for cpu 3
    [229515.002908] CPU: 3 PID: 28735 Comm: bash Tainted: P        W  OE     5.8.10-1-default #1 openSUSE Tumbleweed
    [229515.002909] Hardware name: Canyon/, BIOS MKQ7710H.86A.0074.2018.1025.1727 10/25/2018
    [229515.002911] Call Trace:
    [229515.002924]  dump_stack+0x6b/0x88
    [229515.002930]  ? lapic_can_unplug_cpu.cold+0x3e/0x3e
    [229515.002933]  nmi_cpu_backtrace.cold+0x14/0x52
    [229515.002936]  nmi_trigger_cpumask_backtrace+0xf6/0xf8
    [229515.002941]  __handle_sysrq.cold+0x43/0x110
    [229515.002944]  write_sysrq_trigger+0x24/0x32
    [229515.002948]  proc_reg_write+0x51/0x90
    [229515.002951]  vfs_write+0xc7/0x1f0
    [229515.002954]  ksys_write+0x5f/0xe0
    [229515.002958]  do_syscall_64+0x4d/0xd0
    [229515.002963]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [229515.002967] RIP: 0033:0x7f4530938a93
    [229515.002970] Code: 8b 15 01 f4 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
    [229515.002971] RSP: 002b:00007ffc851a5928 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [229515.002973] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f4530938a93
    [229515.002974] RDX: 0000000000000002 RSI: 00005590703b55a0 RDI: 0000000000000001
    [229515.002975] RBP: 00005590703b55a0 R08: 000000000000000a R09: 0000000000000000
    [229515.002977] R10: 000055906e94361a R11: 0000000000000246 R12: 0000000000000002
    [229515.002978] R13: 00007f4530a09500 R14: 0000000000000002 R15: 00007f4530a09700
    Nope, nothing reconfigured... :-(


    Fun fact: after the copying was over, the 9 smb threads, the 100% CPU and the 80°C core temperature PERSISTED. I had a look at it for an hour or so (just in case some cache still gets transfered, but there was no network activity and nothing written on the target NAS).

    I rebooted to stop this. Strange.
    Kind regards

    raspu

  4. #14

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by tsu2 View Post
    Your iotop unsurprisingly says that 100% of of your CPU is allocated to writing, and more specifically to your sda2 (likely where you mounted your network share).

    One really fundamental principle you have to know in the first place is that
    Reads involve almost no load. All you're doing is detecting data on the disk and storing a copy usually in memory and assembling the pieces together to be the original file.
    Writes on the other hand are processing intensive, but not always CPU intensive. Better disk firmware will do most of the work in silicon both in the disk and on your systemboard. Writes are complex, the disk likely will have pre-allocated or on demand different sizes of sequential blocks (may be related to disk fragmentation), the file to be written is broken up into typically 256k blocks and depending on the disk technology placed in the disk storage in an organized way. There may be related functions to ensure data integrity.

    There will likely be additional functions involved related to the type of file transfer over remote and network connections.

    What this means is that
    Unsurprisingly your source (original location of your files) has no load because you're just reading from disk which is always an insignificant load.
    Your TW machine appears to be performing all the work writing to the remote disk, the machine where the disk is located hardly has to do anything. This is a bit surprising to me but probably can be explained easily... When a file is written, a number of things have to happen of which some will be handled by your disk controller firmwares in your disk and on your systemboard, but some will be handled by your operating system... primarily the collection of the file file pieces, aggregating and piecing into blocks of appropriate size for transfer, and performing whatever other functions are supported by the operation... I haven't looked closely at the SMB protocol, but assume that integrity functions are performed like checksums, and perhaps even supports atomicity, which means that the transfers of each chunk of data has to be successful else the entire operation is cancelled and rolled back. Files being transferred may also be temporarily stored as temporary files until the entire transfer is completed and its integrity verified before finally copied to its final destination... All of which requires more calculations and more writes (plus deletes).

    What I'm saying is that file transfers aren't necessarily simple operations, and there may be a lot happening under the hood.
    To fully understand all this, you'd probably want to read some documentation about the file systems involved, the SMB protocol being used at the Developer level.

    HTH,
    TSU
    tldr: smb is a b*tch eeeehm a beast... :-D
    Kind regards

    raspu

  5. #15

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Malcolm, I tried again after the reboot:

    Code:
    # journalctl -f
    -- Logs begin at Wed 2020-07-22 21:59:58 CEST. --
    Oct 01 10:22:03 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:03 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:05 dell6 su[16751]: (to root) usser on pts/2
    Oct 01 10:22:05 dell6 su[16751]: pam_unix(su-l:session): session opened for user root(uid=0) by user(uid=1000)
    Oct 01 10:22:06 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:06 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:24 dell6 kernel: sysrq: Changing Loglevel
    Oct 01 10:22:24 dell6 kernel: sysrq: Loglevel set to 1
    Oct 01 10:22:27 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:32 dell6 kernel: sysrq: Changing Loglevel
    Oct 01 10:22:32 dell6 kernel: sysrq: Loglevel set to 1
    The only thing triggered by

    Code:
    echo 1 > /proc/sysrq-trigger
    is this "Changing Loglevel" ...

    No idea what that means.
    Kind regards

    raspu

  6. #16
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,679
    Blog Entries
    15

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by suse_rasputin View Post
    Malcolm, I tried again after the reboot:

    Code:
    # journalctl -f
    -- Logs begin at Wed 2020-07-22 21:59:58 CEST. --
    Oct 01 10:22:03 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:03 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:05 dell6 su[16751]: (to root) usser on pts/2
    Oct 01 10:22:05 dell6 su[16751]: pam_unix(su-l:session): session opened for user root(uid=0) by user(uid=1000)
    Oct 01 10:22:06 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:06 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:24 dell6 kernel: sysrq: Changing Loglevel
    Oct 01 10:22:24 dell6 kernel: sysrq: Loglevel set to 1
    Oct 01 10:22:27 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:30 dell6 plasmashell[1783]: qml: temp unit: 0
    Oct 01 10:22:32 dell6 kernel: sysrq: Changing Loglevel
    Oct 01 10:22:32 dell6 kernel: sysrq: Loglevel set to 1
    The only thing triggered by

    Code:
    echo 1 > /proc/sysrq-trigger
    is this "Changing Loglevel" ...

    No idea what that means.
    Hi
    All very strange indeed.... including the load issue, I think it's a driver issue with the interface, what module is in use (maybe able to enable some debug)?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  7. #17

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    I have here

    Code:
    lspci -v
    ...
    06:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)
            Subsystem: Dell Device 026d
            Flags: bus master, fast devsel, latency 0, IRQ 47
            Memory at f5be0000 (64-bit, non-prefetchable) [size=64K]
            Memory at f5bf0000 (64-bit, non-prefetchable) [size=64K]
            Capabilities: [48] Power Management version 3
            Capabilities: [40] Vital Product Data
            Capabilities: [60] Vendor Specific Information: Len=6c <?>
            Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
            Capabilities: [cc] Express Endpoint, MSI 00
            Capabilities: [100] Advanced Error Reporting
            Capabilities: [13c] Virtual Channel
            Capabilities: [160] Device Serial Number bc-30-5b-ff-xx-xx-xx-yy
            Capabilities: [16c] Power Budgeting <?>
            Kernel driver in use: tg3
            Kernel modules: tg3
    ...
    How to "reset" the logging to the expected behaviour? Fresh install? The machine normally has no internet access, only from time to time for some youtube...


    I started to copy some large files (44.5 GB) to a smb share hosted on the very same Dell-TW machine (accessed via smb !) from the Odroid NAS via Dolphin on Dell-TW machine.

    2 smbd processes at 20% of a CPU, refreshing 65MiB/s---

    Will test the other direction afterwards...
    Kind regards

    raspu

  8. #18
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,679
    Blog Entries
    15

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by suse_rasputin View Post
    I have here

    Code:
    lspci -v
    ...
    06:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)
            Subsystem: Dell Device 026d
            Flags: bus master, fast devsel, latency 0, IRQ 47
            Memory at f5be0000 (64-bit, non-prefetchable) [size=64K]
            Memory at f5bf0000 (64-bit, non-prefetchable) [size=64K]
            Capabilities: [48] Power Management version 3
            Capabilities: [40] Vital Product Data
            Capabilities: [60] Vendor Specific Information: Len=6c <?>
            Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
            Capabilities: [cc] Express Endpoint, MSI 00
            Capabilities: [100] Advanced Error Reporting
            Capabilities: [13c] Virtual Channel
            Capabilities: [160] Device Serial Number bc-30-5b-ff-xx-xx-xx-yy
            Capabilities: [16c] Power Budgeting <?>
            Kernel driver in use: tg3
            Kernel modules: tg3
    ...
    How to "reset" the logging to the expected behaviour? Fresh install? The machine normally has no internet access, only from time to time for some youtube...


    I started to copy some large files (44.5 GB) to a smb share hosted on the very same Dell-TW machine (accessed via smb !) from the Odroid NAS via Dolphin on Dell-TW machine.

    2 smbd processes at 20% of a CPU, refreshing 65MiB/s---

    Will test the other direction afterwards...
    Hi
    AFAIK the 1 should trigger it all.... https://www.kernel.org/doc/html/late...ide/sysrq.html
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  9. #19

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    From Odroid NAS to SMB share on Dell machine (via smb in Dolphin on Dell machine) I get 67 MiB/s, again 2 processes in htop, not much load on processors... strange...
    Kind regards

    raspu

  10. #20
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,679
    Blog Entries
    15

    Default Re: Why is my hexacore Xeon at 100% for copying some files via samba?

    Quote Originally Posted by suse_rasputin View Post
    From Odroid NAS to SMB share on Dell machine (via smb in Dolphin on Dell machine) I get 67 MiB/s, again 2 processes in htop, not much load on processors... strange...
    Hi
    Looks like it's a wait and see issue.....
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

Page 2 of 4 FirstFirst 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •