Ubuntu 19.04がディスクSSDへの書き込み時にフリーズする
18.10から19.04に更新しました（以前はDebian Stretchから）。アップグレード以降、書き込み操作を行うと、マウスを含むシステム全体が3秒以上フリーズします。アップグレードの前に発生しなかったので、それはかなり奇妙です、そしてシステムは同じです。 hdparmは517 MB/sの読み取りを報告し、smartはエラーを表示していません：
Sudo smartctl -a /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-5.0.0-13-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: LITEON L8H-128V2G-11 M.2 2280 128GB
Serial Number: BR0RJW291CB0075GB0VE
Firmware Version: F87110C
User Capacity: 128.035.676.160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: M.2
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Apr 20 11:47:56 2019 -03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x02) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x11) SMART execute Offline immediate.
No Auto Offline data collection support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
No Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 10) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0003 100 100 000 Pre-fail Always - 0
9 Power_On_Hours 0x0002 100 100 000 Old_age Always - 681
12 Power_Cycle_Count 0x0003 100 100 000 Pre-fail Always - 535
175 Program_Fail_Count_Chip 0x0003 100 100 000 Pre-fail Always - 0
176 Erase_Fail_Count_Chip 0x0003 100 100 000 Pre-fail Always - 0
177 Wear_Leveling_Count 0x0003 100 100 000 Pre-fail Always - 76
178 Used_Rsvd_Blk_Cnt_Chip 0x0003 100 100 000 Pre-fail Always - 0
179 Used_Rsvd_Blk_Cnt_Tot 0x0003 100 100 000 Pre-fail Always - 0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0003 100 100 000 Pre-fail Always - 147
181 Program_Fail_Cnt_Total 0x0003 100 100 000 Pre-fail Always - 0
182 Erase_Fail_Count_Total 0x0003 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0003 100 100 000 Pre-fail Always - 0
195 Hardware_ECC_Recovered 0x0003 100 100 000 Pre-fail Always - 0
241 Total_LBAs_Written 0x0003 100 100 000 Pre-fail Always - 215371
242 Total_LBAs_Read 0x0003 100 100 000 Pre-fail Always - 68520
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 58 -
# 2 Short offline Completed without error 00% 58 -
# 3 Short offline Completed without error 00% 58 -
# 4 Short offline Completed without error 00% 0 -
Selective Self-tests/Logging not supported
fstabには、LVMを備えたシステムに共通のオプションがあります。
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/euclides--vg-root / ext4 noatime,nodiratime,errors=remount-ro 0 1
# /boot was on /dev/sdb1 during installation
UUID=456b218a-f23c-4a35-8b39-ad416b03204f /boot ext2 defaults 0 2
/dev/mapper/euclides--vg-home /home ext4 defaults 0 2
/swapfile none swap sw 0 0
何が起こっているのか、これを修正する方法についてのアイデアはありますか？
[〜＃〜] edit [〜＃〜]：テストのために、GnomeからKDEに切り替えましたが、驚いたことに、遅れはなくなりました。したがって、これはおそらく私のSSDの問題ではなく、実際にはGnomeに関連するものでした。
Ubuntu 19.04にnVIDIAとGnome 3.32がある場合は、以下に従ってください https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/post/5323965/#5323965 次のように変数を追加します。
Sudo gedit /etc/environment
__GL_MaxFramesAllowed=1
私のDell 7577ラップトップ（max-QデザインのnVIDIA GTX 1060を搭載）では、ThunderbirdやFirefoxなどのアプリケーションを起動すると、Ubuntu 18.10から19.04へのアップグレードが2秒間フリーズしました。また、VLCはどもりました。上記の変数を使用すると、私のgnomeはスムーズに実行されます。
ここで説明するAPSTバグにぶつかった可能性があります。
1。 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184
2。 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1689357
彼らは/ etc/default/grubを編集してカーネルパラメーターを追加することを提案しています nvme_core.default_ps_max_latency_us = xxx カーネルコマンドライン
さまざまなデバイス用、 xxx それが動作する場合は異なります 、（最大5500）に増やして、より深い省電力状態を実現できます。編集後、再起動する前にupdate-grubを実行することを忘れないでください。とにかく、スレッドを読みます。
ここではまったく同じですが、Ubuntuの代わりに、Debian StretchをDebian Busterに更新しています。端末で単純なtouch helloを実行するだけで、3秒間フリーズし、gnome-ShellでのCPU使用率が高くなります。
私はそのユーザーをStretchで何年も使用しているため、大量のドキュメントと構成があります。
コメントが示唆するように、私はKDEに行きたくありませんでした。だから、私がしたことは、問題がまったく新しいユーザーで起こっているかどうかを確認することでした。新しいユーザーでは、まったく問題ありません。
だから、私の解決策は：
- すべてのセッションからログアウトする
- コンソールにrootとしてログインします
mv /home/myusualuser /home/myusualuser2mkdir /home/myusualuserchown myusualuser:myusualuser /home/myusualuser- そして、myusualuserとして再度ログインします
問題はなくなりました。
現在、ファイルを徐々に移動しています。どのディレクトリ/ファイル/構成が問題を引き起こしていたかを見つけたら、このエントリを更新します。
私は同じ問題が発生していたと確信しています。ここに私が気づいたいくつかのことがありました：
- しばらく実行した後、フリーズが悪化する傾向がありました（システムが長時間ハングする）
- 通常、サスペンドからの再開、ダウンロードしたファイルをFirefoxのデスクトップに保存、ファイル選択ダイアログを閉じると（たとえば、電子メールの添付ファイルをアップロードしたり、ドキュメントを開いたり）、数秒間ハングし、実際にファイルへのアクセスまたはダイアログのキャンセルを選択しました
- 単純なWeb作業と数回のサスペンド/レジュームサイクルの1日の後、私のシステムは、ハードウェア（まったく新しいシステム、SSD、第8世代i7、16 GB RAM、これは手に負えないはずです）によってまったく正当化されない方法で反応が鈍くなります。ワープロとGmailによる）
- 18.10から19.04にアップグレードする前は、問題はまったくありませんでした。
私は19.10にアップグレードしましたが、問題はそれほど明白ではありません。アップグレード直後、ハングは数秒ではなく1秒未満に減少しました。システムはまだわずかにハングしているように見えましたが、それほど気にしていたわけではありません。
しかし、私は自分のデスクトップ上に多くのファイルを保持する傾向もあります-私たちはいつでも少なくとも60〜200話しています。それらの多くは小さいですが、かなり大きいものもあります（Linux ISOなど）。直感的に、これらのすべてのファイルをデスクトップから削除しましたが、ハングは完全になくなったようです。 19.04未満でも、デスクトップをクリーンアップすることでこの問題は解決したと思いますが、この仮説を検証するために戻るつもりはありません。
19.10にアップグレードしたり、デスクトップをクリーンアップしたりすることで、同様の問題を抱えている他の人が役に立ったかどうか知りたいです。