Disk read error outofmemoryerror ошибка zona

В некоторых редких случаях пользователь torrent-клиента может столкнуться с ошибкой «Write to disk. Отказано в доступе». Такая проблема возникает тогда, когда торрент-программа пытается скачать файлы на жесткий диск, но сталкивается с некоторыми препятствиями. Обычно, при такой ошибке загрузка останавливается примерно на 1% — 2%. Существует несколько возможных вариантов возникновения данной проблемы.

Причины возникновения ошибки

Суть ошибки состоит в том, что торрент-клиенту отказано в доступе при записи данных на диск. Возможно программа не имеет прав для записи. Но кроме этой причины существует множество других. В данной статье будут перечислены самые вероятные и распространённые источники проблем и их решения.

Как уже было упомянуто, ошибка Write to disk довольно редкая и имеет несколько причин возникновения. Чтобы её исправить вам понадобится несколько минут.

Причина 1: Блокировка вирусами

Вирусное ПО, которое могло поселиться в системе вашего компьютера, может принести множество проблем, среди которых и ограничение доступа torrent-клиента к записи на диск. Рекомендуется использовать портативные сканеры на выявление вирусных программ, так как обычный антивирус может не справиться с данной задачей. Ведь если он упустил эту угрозу, то есть вероятность того, что он совсем её не найдёт. В примере будет использоваться бесплатная утилита Doctor Web Curelt!. Вы можете просканировать систему любой другой удобной вам программой.

Запустите сканер, согласитесь с участием в статистике Доктор Веб. После нажмите «Начать проверку».

Начнётся процесс проверки. Он может длиться несколько минут.

Причина 2: Недостаточно свободного места на диске

Возможно диск, на который загружаются файлы заполнен до отказа. Чтобы освободить немного места, придётся удалить некоторые ненужные объекты. Если у вас ничего такого нет удалять, а места мало и некуда перенести, то стоит воспользоваться облачными хранилищами, которые бесплатно предлагают гигабайты пространства. Например, подойдут Google Drive, Dropbox и другие.

Если у вас в компьютере беспорядок и вы не уверены точно, что на диске нет дублирующих файлов, то существуют программы, которые помогут в этом разобраться. Например, в CCleaner существует такая функция.

1. В программе Ccleaner перейдите во вкладку «Сервис», а потом в «Поиск дублей». Вы можете настроить нужные вам параметры.
2. Когда нужные галочки будут поставлены нажмите «Найти».

Причина 3: Некорректная работа клиента

Возможно, torrent-программа стала некорректно работать или её настройки были повреждены. В первом случае нужно перезапустить клиент. Если же вы подозреваете, что проблема в повреждённом компоненте программы, нужно переустановить torrent с чисткой реестра или попытаться скачать файлы с помощью другого клиента.
Чтобы устранить проблему записи на диск, попробуйте перезапустить торрент-клиент.

Полностью выйдите с торрента, нажав на соответствующий значок в трее правой клавишей мыши и выбрав «Выход» (пример показан на BitTorrent, но практически во всех клиентах все аналогично).

Теперь нажмите на ярлык клиента правой кнопкой и выберите «Свойства».

В окне выберите вкладку «Совместимость» и поставьте галочку на пункте «Выполнять эту программу от имени администратора». Примените изменения.

Если у вас Windows 10, то есть смысл поставить режим совместимости с Windows XP.

Во вкладке «Совместимость» поставьте галочку напротив «Запустить программу в режиме совместимости с» и в нижнем списке настройте «Windows XP (пакет обновления 3)».

Причина 4: Путь сохранения файла написан кириллицей

Такая причина довольно редкая, но вполне реальная. Если вы собираетесь менять имя пути загрузки, тогда нужно указать этот путь в настройках торрента.

Зайдите в клиенте в «Настройки» — «Настройки программы» или используйте сочетание Ctrl+P.

Если у вас есть незавершённая загрузка, кликните на неё правой клавишей и наведите на «Дополнительно» — «Загружать в» выбрав соответствующую папку. Это нужно проделать для каждого недозагруженного файла.

Другие причины

• Возможно ошибка записи на диск связана с кратковременным сбоем. В таком случае, перезагрузите компьютер;
• Антивирусная программа может блокировать torrent-клиент или как раз сканировать недогружённый файл. Отключите защиту на некоторое время для нормальной закачки;
• Если один объект загружается с ошибкой, а остальные нормально, то причина кроется в криво залитом torrent-файле. Попробуйте совсем удалить загружённые фрагменты и закачайте их заново. Если этот вариант не помог, то стоит найти другую раздачу.

В основном, для устранения ошибки «Отказано в доступе Write to disk», используют запуск клиента от имени администратора или смену директории (папки) для файлов. Но остальные методы тоже имеют право жить, ведь проблема не всегда может ограничиваться лишь двумя причинами.

Отблагодарите автора, поделитесь статьей в социальных сетях.

By Rodin | Last Updated November 07, 2019

• Facebook
• Twitter
• Linkedin
• Reddit

Summary :

Steam is a popular social gaming website where you can buy, play, and discuss games. But, have you ever received Steam disk write error while installing or updating games? Were you ever able to find an effective solution? If you had a difficult time, this post should be helpful to you.

Quick Navigation :

Steam Disk Write Error While Downloading/Installing

While installing or updating a game like Dota 2, Fallout 4, Grand Theft Auto V and PlayerUnknown’s Battlegrounds, Steam sometimes displays an error message which reads, «An error occurred while installing/updating [game title] (disk write error)».

See image below.

Commonly known as Steam disk write error, this issue can occur anytime when a game is updated or installed on Steam, leading to Steam being unable to complete the installation. Disk write error shown in the parenthesis is the specific reason responsible for the error.

How to fix disk write error Steam? If you are having troubles updating a game or installing a game on Steam due to a disk write error now, try the following solutions out.

Steam Disk Write Error Fix Provided by Users

1. Run as Administrator

Go to the file location of Steam (default location is C:/program files[86]/Steam). Right-click on the steam.exe and go to properties. Head to the Compatibility tab in properties and make sure, «run this program as an administrator», is ticked. Click Apply and run Steam again. Check if the Steam disk write error has been solved.

2. Delete the 0KB File

This solution is provided by a Reddit user and many users rate it useful. In short, he just solved this issue by going into Program Files (x86)/Steam/steamapps/common and simply deleting a file titled «Fallout» that was 0KB in size. When he re-launched the game, Fallout 4 loaded up perfectly. This solution might also be useful when updating similar games. See the original post here.

3. Remove Write Protection

When a disk is write-protected, you’re unable to modify the formatting and writing. This is another possible reason for the Steam disk write error. Please make sure the directory of Steam is NOT read-only. Then right click your Steam launch icon and click Run as administrator.

But if the disk is already written protected, you can simply clear write protection and remove the error using command.

Take Windows 10 for instance.

Run Command Prompt as an Administrator. Then type these commands one by one and press the Enter key after each:

• diskpart
• list disk
• select disk # (# is the number of the hard drive with which you’re getting the disk error)
• attributes disk clear readonly

You may now close Command Prompt, repeat the downloading/upgrading process and check if the Steam disk write error Windows 10 disappeared.

4. Delete Corrupted Files in Log

Go to Steam/logs/content_log and open it. Scroll to the bottom of the log file, and look for a «failed to write» error, which will list the file name & path of the issue. Please follow the path to delete the corrupted file, and then repeat the downloading/upgrading.

5. Check Hard Drive for Errors

All storage drives/devices can be affected by file corruption, especially if it has run for years or running under a heavy load. You’ll want to work with a tech support specialist to investigate possible issues with your Steam hard drive.

For Windows: My PC -> Right-click on the drive for Steam -> Properties -> Tools -> Error checking

If you are not specialized, but want to do it by yourself, MiniTool Partition Wizard Free is a good recommendation. Its Check File System and Surface Test feature can lead you through the disk check process easily and quickly. Applies to all Windows 7/8/8.1/10 editions.

Download this freeware, install it on computer and follow the guide below:

Step 1. Launch this free partition magic to the main interface. At the disk map area, select the partition that has Steam installed and choose Check File System from the Check Partition group.

Step 2. In the new emerging window, select Check & fix detected errors and click the Start button. Please wait patiently until it finishes the job. If any error is found, Partition Wizard will try its best to fix it.

Now it is time to test whether there are bad sectors on the drive bringing Steam disk write error to Windows 10/8/7.

Step 3. Select the disk that has Steam installed and reports Steam disk write error and then choose Surface Test from the Check Partition group.

Step 4. In the new emerging window, click Start Now on the top right corner to begin the check. Note that if there are read errors found, they will be marked with red color. On the contrary, if no bad sector is found, all will be marked with green.

If no error is found, go back to Steam and see if the Steam game update is stuck still.

If a lot of errors are found and your drive looks like a failing disk, this may be responsible for the Steam downloading/upgrading error. In this case, it is better for you to back up data on the drive as soon as possible and then replace the drive. Luckily, MiniTool Partition Wizard Free is also capable of doing this work.

Follow the simple guide below:

Step 1. At the disk map error, select the hard drive which has Steam installed and choose Copy Disk from the left action panel.

Step 2. Select a target disk to save all data on the source disk. Be aware that all data on the selected target disk will be cleaned for a successful clone. Thus, it is necessary to transfer important data to a safe place.

Step 3. Review the changes to be made or change the copy options according to your preference.

Step 4. Read how to boot from the target disk if you have such an intention.

Step 5. Click Apply to put the pending operations into effect and wait patiently until MiniTool Partition Wizard finishes.

But if the above user’s experience does not help, you may continue reading the solutions put forward by Steam.

Official Steam Troubleshooting

1. Restart Steam and Computer

Needless to say, restarting is always the first thing to try. Please restart Steam and then repeat the downloading/upgrading. If the Steam disk write error persists, restart your computer.

2. Clear Download Cache

Clearing the download cache of Steam will force the Steam client to flush locally cached configuration data and acquire it from the Steam server again.

Please follow this path to do the clean: Steam > Settings > Downloads > Clear Download Cache

3. Reinstall Steam

Reinstalling Steam may fix potential issues with Steam client and service files while preserving all installed games. Remember: DO NOT uninstall (this may delete all game content), just reinstall Steam to the same location.

4. Repair Library Folder

The Steam Library contains all your installed games which should be writable by all users so as to download or update properly. However, sometimes Steam game update stuck because the user permissions changed and need to be refreshed.

Please follow this path to do the repair: Steam > Settings > Downloads > Steam Library Folders > Right click on folder > Repair Folder

5. Verify Local Files

Bad hardware, software crashes, and power surges can corrupt the game folders. You can use Steam to verify the integrity of these files and fix them if necessary.

Find Game in Library > Right click on Properties > Local Files > Verify Integrity of Game Files

6. Change Download Region

The Steam content system is divided into geographical regions. The Steam client automatically detects its current region and uses content servers located in that region.

Sometimes, servers in a specific region may be slow or overloaded, leading to Steam disk write error while downloading. You can switch to a different download region, using another set of content servers to have a try.

Please go to Steam > Settings > Downloads > Download Region. You may need to test several regions other than your own.

7. Move Game Folder

It is worth trying to install the game on another hard drive in case it is the hard drive failure. If this works, you can then create a new Steam Library folder on this drive and install new games or move the already installed games into this Steam Library folder.

Please go to Steam > Settings > Downloads > Steam Library Folders > Add New Library Folder

8. Refresh Local Network Hardware

Network hardware can get into a slow/broken state after running for a long time. Restarting all modems & routers might be helpful to fix Steam disk write error.

9. Update System & Drivers

Make sure your operating system and hardware drivers are all up to date and repeat the downloading/upgrading.

For Windows: Start > Search «update» > Run «Check for Updates»

For Mac: drivers cannot be updated separately; you can only update the operating system to the latest.

10. Investigate Firewalls

Certain firewalls may prevent Steam from talking to its servers. You can temporarily disable it for testing purpose. If that’s the reason, it may be necessary to add exceptions in your firewalls for Steam.

11. Investigate Anti-Virus

Anti-Virus hooks deep into the operating system and can affect disk and network operations, further leading to issues with Steam. Besides, some games use copy protection technology which may appear as malicious software to an antivirus scanner, resulting in Steam disk write error. You can completely disable the Anti-Virus and check if the disk write error stopped.

12. Investigate Other Programs & Services

Software that modifies or monitors systems and disk or network activity can cause issues while downloading or running a game. These programs and services can run in the background and are typically associated with software like Anti-Virus, ad-blockers, web-optimizers, firewalls, system cleaners, etc.

You may work with a tech support specialist to ensure that these services & programs are not interfering with Steam. You may even need to temporarily disable them for testing purposes.

13. Disable Overclocking

Some users overclock their hardware to gain the best performance without accepting manufacturers’ recommended settings. This can cause memory and file corruption and should be disabled (usually you can do this in the computer BIOS).

14. Test Online Connection

Some Internet providers cache or compress online data to save bandwidth. This can cause issues with Steam. It is good to try connecting your PC to an entirely different network from a different service provider to fix disk write error Steam.

15. Check RAM for Errors

Memory errors can cause issues with the Steam installation process, as well as gameplay. You’ll want to work with a tech support specialist to investigate possible issues with your system memory.

For Windows: Start -> Find «mdsched» and run Windows Memory Diagnostic

Bottom Line

Here we come to the end of this post. Now you know what Steam disk write error installing/updating is and how to resolve it with multiple methods. Hopefully some of our suggestions help you solve any issues early on.

If you have any other tried and true strategies on the subject of how to remove the disk write error on Steam, let us know by typing your suggestions in the comment section below. If you have any difficulty in using MiniTool software, you can send email to [email protected] .

Если Вы скачиваете торренты из сети, то наверняка сталкивались с таким явлением: программа внезапно прекращает загрузку файлов и сообщает об ошибке. В случае с utorrent она звучит как «Отказано в доступе Write to disk». В случае с qbittorrent – «Произошла ошибка ввода/вывода для торрента».

Почему возникает ошибка торрента? Виной тому может быть целый ряд факторов… Например, нехватка места на жестком диске (как на скриншоте выше). Также причиной может быть нарушение целостности файлов в результате сбоя работы диска. Ну а уже сбой диска может вызываться в свою очередь целым «букетом» факторов: наличие битых bad-секторов, плохой контакт разъема шлейфа, деятельность вирусов и пр.

Все вновь загружаемые файлы будут помещаться в новую папку, а Вам осталось туда же перенести имеющиеся на закачке торренты. Для этого выделите их в списке загрузок, выберите опцию «Дополнительно» -> «Загружать в…» и укажите новую папку.

Друзья, помог ли Вам справиться с ошибкой загрузки и доступа к торренту один из этих способов? Делитесь в комментариях.

A disk read error occurred — как исправить

Иногда при включении компьютера можно столкнуться с ошибкой «A disk read error occurred. Press Ctrl+Alt+Del to restart» на черном экране, при это перезагрузка, как правило, не помогает. Ошибка может возникнуть после восстановления системы из образа, при попытке загрузки с флешки, а иногда и без каких-то видимых причин.

В этой инструкции подробно об основных причинах ошибки A disk read error occurred при включении компьютера и о способах исправить проблему.

Причины ошибки disk read error occurred и способы исправления

Сам по себе текст ошибки говорит о том, что произошла ошибка чтения с диска, при этом, как правило имеется в виду диск, с которого выполняется загрузка компьютера. Очень хорошо, если вы знаете, что предшествовало (какие действия с компьютером или события) появлению ошибки — это поможет более точно установить причину и выбрать метод исправления.

Среди наиболее распространенных причин, вызывающих появление ошибки «A disk read error occurred» можно выделить следующие

1. Повреждение файловой системы на диске (например, в результате неправильного выключения компьютера, отключения электричества, сбоя при изменении разделов).
2. Повреждение или отсутствие загрузочной записи и загрузчика ОС (по вышеозначенным причинам, а также, иногда, после восстановления системы из образа, особенно созданным сторонним ПО).
3. Неправильные настройки БИОС (после сброса или обновления БИОС).
4. Физические проблемы с жестким диском (диск вышел из строя, давно работал не стабильно, или после падения). Один из признаков — при работе компьютер то и дело зависал (когда включался) без видимых причин.
5. Проблемы с подключением жесткого диска (например, вы плохо или неправильно его подключили, поврежден кабель, повреждены или окислены контакты).
6. Недостаток питания вследствие выхода блока питания из строя: иногда при недостатке питания и неисправностях блока питания компьютер продолжает «работать», но некоторые компоненты могут самопроизвольно отключаться, в том числе — жесткий диск.

Исходя из этой информации и в зависимости от ваших предположений о том, что способствовало появлению ошибки, можно попробовать исправить её.

Прежде чем приступать, убедитесь, что диск, с которого выполняется загрузка, виден в БИОС (UEFI) компьютера: если это не так, вероятнее всего, проблем в подключении диска (перепроверьте подключение кабелей как со стороны самого диска, так и со стороны материнской платы, особенно если у вас системный блок находится в открытом виде или вы недавно выполняли какие-либо работы внутри него) или в его аппаратной неисправности.

Если ошибка вызвана повреждением файловой системы

Первое и самое безопасное — выполнить проверку диска на ошибки. Для этого потребуется загрузить компьютер с какой-либо загрузочной флешки (или диска) с утилитами диагностики или с обычной загрузочной флешки с любой версией Windows 10, 8.1 или Windows 7. Приведу метод проверки при использовании загрузочной флешки Windows:

1. Если загрузочной флешки нет, создайте её где-то на другом компьютере (см. Программы для создания загрузочной флешки).
2. Загрузитесь с неё (Как поставить загрузку с флешки в БИОС).
3. На экране после выбора языка нажмите «Восстановление системы».
4. Если у вас была загрузочная флешка Windows 7, в средствах восстановления выберите «Командная строка», если 8.1 или 10 — «Поиск и устранение неисправностей» — «Командная строка».
5. В командной строке введите по порядку команды (нажимая Enter после каждой из них).
6. diskpart
7. list volume
8. В результате выполнения команды на шаге 7 вы увидите букву системного диска (в данном случае она может отличаться от стандартной C), а также, при их наличии — отдельные разделы с загрузчиком системы, которые могут не иметь буквы. Для проверки её потребуется назначить. В моем примере (см. скриншот) на первом диске есть два раздела, которые не имеют буквы и которые имеет смысл проверить — Том 3 с загрузчиком и Том 1 со средой восстановления Windows. В следующих двух командах назначаю букву для 3-го тома.
9. select volume 3
10. assign letter=Z (буква может быть любая не занятая)
11. Аналогично назначаем букву для других томов, которые следует проверить.
12. exit (этой командой выходим из diskpart).
13. Поочередно проверяем разделы (главное — проверить раздел с загрузчиком и системный раздел) командой: chkdsk C: /f /r (где C — буква диска).
14. Закрываем командную строку, перезагружаем компьютер, уже с жесткого диска.

Если на 13-м шаге на каком-то из важных разделов были найдены и исправлены ошибки и причина проблемы была именно в них, то есть вероятность, что следующая загрузка пройдет успешно и ошибка A Disk Read Error Occurred вас больше не потревожит.

Повреждение загрузчика ОС

Если есть подозрения, что ошибка при включении вызвана повреждением загрузчика Windows, используйте следующие инструкции:

Проблемы с настройками БИОС/UEFI

Если ошибка появилась после обновления, сброса или изменения параметров БИОС, попробуйте:

• Если после обновления или изменения — сбросить параметры БИОС.
• После сброса — внимательно изучить параметры, особенно режим работы диска (AHCI/IDE — если не знаете, какой выбрать, попробуйте оба варианта, параметры находятся в разделах, связанных с конфигурацией SATA).
• Обязательно проверьте порядок загрузки (на вкладке Boot) — ошибка может быть вызвана и тем, что нужный диск не выставлен в качестве устройства загрузки.

Если ничто из этого не помогает, а проблема связана с обновлением БИОС, уточните, есть ли возможность установить предыдущую версию на вашу материнскую плату и, если есть, попробуйте сделать это.

Проблема с подключением жесткого диска

Рассматриваемая проблема может быть вызвана и проблемами с подключением жесткого диска или работой SATA шины.

• Если вы проводили работы внутри компьютера (или он стоял открытым, и кто-то мог задеть кабели) — переподключите жесткий диск как со стороны материнской платы, так и со стороны самого диска. Если есть возможность, попробуйте другой кабель (например, от DVD-привода).
• Если вы установили новый (второй) накопитель, попробуйте отключить его: если без него компьютер загружается нормально, попробуйте подключить новый диск к другому разъему SATA.
• В ситуации, когда компьютер долгое время не использовался и хранился не в идеальных условиях, причиной могут быть окисленные контакты на диске или кабеле.

Если ни один из способов не помогает решить проблему, при этом жесткий диск «виден», попробуйте переустановку системы с удалением всех разделов на этапе установки. Если через короткий промежуток после переустановки (или сразу после неё) проблема вновь заявит о себе — велика вероятность, что причина ошибки в неисправности жесткого диска.

Источник

«A disk read error occurred» — как исправить эту ошибку чтения диска (появилась сразу после включения компьютера)

Сегодня из ниоткуда на экране ПК появилась одна пакость: «A disk read error occurred. Press Ctrl+Alt+Del». С системой ничего не делал: не удалял, не обновлял, не устанавливал. и т.д.

Есть подозрение только на одно: я накануне часа 2 вечером копировал фильмы на флешки и DVD-диски. Может с диском что-то случилось? Подскажите, как это можно исправить.

Если перевести эту ошибку на русский (для более простого понимания широкой аудитории) — то она означает, что «Произошла ошибка чтения диска». Возникать она может не всегда из-за поломки диска (хватает и других причин: сбившиеся настройки BIOS; неправильное отключение, приведшее к ошибкам файловой системы и т.д.).

Ниже, постараюсь в пошаговом и простом «стиле» представить первичную диагностику. Думаю, большинство с ней справятся. 👌

Что можно посоветовать для исправления ошибки чтения диска

ШАГ 1

И так, первый совет банальный : проверьте и отключите от компьютера все флешки, CD/DVD-диски, внешние HDD, дискеты и т.д. (тем более, если вы накануне что-то записывали на эти типы накопителей).

Примечание: многие пользователи, скинув на внешний накопитель данные, забывают его в USB и выключают компьютер. А затем, при включении, ПК начинает искать загрузочные записи на этой самой флешке (например) — разумеется, их не находит и возникает ошибка*!

Флешка подключена к USB-порту!

👉 Дополнение: если к компьютеру подключен сканер, принтер, телефон и пр. периферийные устройства — отключите их также на время диагностики. Оставьте мышь, клавиатуру, монитор — т.е. самый «минимум».

Если накануне устанавливали доп. диски (HDD/SSD и пр.) — отключите их!

ШАГ 2

Если первый шаг не помог — следующее, что я порекомендую — это проверить настройки BIOS (UEFI) компьютера.

1) Как войти в БИОС (BIOS) на компьютере / ноутбуке.

👉 В первую очередь в BIOS нужно проверить 2 вещи:

• определяется ли диск (на котором установлена Windows). Видна ли его модель/размер? Если не определяется — см. шаг 3.
• стоит ли диск первым в очереди* загрузки ( примечание : в BIOS можно задавать приоритет накопителей: т.е., например, можно задать, чтобы компьютер сначала искал загрузочную флешку, а если ее нет, загружался с диска. Нам нужно сразу же указать диск. ).

Как правило, модель диска (если он определился) можно увидеть сразу же после входа в BIOS (на странице «Main»). Установлен ли этот диск первым по приоритету загрузки — см. раздел BOOT. Пример привел на фотографиях ниже. 👇

Диск определяется (уже неплохо)

Boot Option #1 — указан диск с ОС Windows (настройки BIOS)

Примечание : после проведенных изменений в BIOS — не забудьте сохранить настройки. Как правило, для этого достаточно нажать клавишу F10.

ШАГ 3 (если не определяется диск)

Это явно указывает на какую-то аппаратную причину. (не всегда не определяющийся диск начал сыпаться и нуждается в замене).

Для начала я бы посоветовал отключить системный блок от питания и посмотреть, не отошел ли какой-нибудь шлейф от диска. Желательно попробовать подключить диск к другому разъему на мат. плате (благо на любой мат. плате есть по несколько SATA-портов).

Не отошли ли шлейфы.

Если диск компьютер так и не увидел, то первое в чем необходимо убедиться — исправен ли он вообще, не пришел ли в негодность. Для этого лучше всего диск подключить к другому компьютеру / ноутбуку. Если у вас есть спец. переходники — диск можно даже подключить к USB-порту (пару ссылок ниже о том, как это сделать).

Подключение SATA и кабеля питания к диску

👉 Кстати!

Компьютер можно использовать даже без диска! Для этого вам понадобиться спец. подготовленная флешка (так называемый «живой» LiveCD) — Windows будет загружена прямо с нее (и она мало чем отличается от обычной ОС).

О том, где загрузить нужный ISO образ с LiveCD и как его правильно подготовить — можете узнать из этой статьи.

ШАГ 4 (если диск определяется)

И так, на этом этапе будем считать, что диск определяется в BIOS, он первый в приоритете загрузки, и с него раньше ПК благополучно загружался.

Для дальнейшей работы нам понадобиться 👉 LiveCD-флешка от Сергея Стрельца.

👉 Загрузившись с нее — необходимо открыть программу Victoria и проверить диск (оценить его состояние — не начал ли он сыпаться (из-за этого, кстати, «часть» диска могла перестать читаться и, как следствие, ошибка «A disk read error occurred»)).

Тестирование быстрое (Quick) — Victoria 5

👉 Если с самим диском всё в порядке — не лишним было бы проверить файловую систему на ошибки (делается также с LiveCD-флешки!).

Для этого необходимо будет открыть командную строку, ввести chkdsk C: /f /r и нажать Enter. 👇 В течении 5-15 мин. (в среднем) диск будет проверен, а ошибки исправлены.

👉 Если вышеприведенное не помогло, то как вариант, можно попробовать с помощью установочной флешки (с Windows) восстановить систему (загрузчик ОС). О том, как это сделать — см. эту заметку.

Восстановление системы (при установке ОС)

👉 Ну и как «последняя инстанция» возможно стоит переустановить систему, или лучше сказать установить вторую ОС в свободное место диска (благо, это можно сделать без затрагивания «старой» Windows, без потери данных и форматирования всего диска).

Источник

A disk read error occurred press ctrl alt del – универсальная инструкция по устранению

Как правило, ошибка «A disk read error occurred. Press Ctrl+Alt+Del to restart» возникает при включении компьютера, при этом не исправляется обычной перезагрузкой. На, то есть несколько причин, от программных до технических. Что делать в этой ситуации? Давайте разбираться.

Общая информация

В переводе на русский «A disk read error occurred» означает ошибку чтения диска. Но это не говорит о том, что есть проблемы с самим жестким диском или SSD на котором установлена Windows.

Выделю распространенные причины появления сбоя.

1. Повредилась файловая система. Обычно это происходит при неправильном выключении компьютера, например, после резкого выключения электричества или наличии вирусов.
2. Повреждение загрузчика «MBR».
3. Неверные настройки BIOS, в том числе измененный порядок загрузки устройств.
4. Неисправность жесткого диска. Особенно если до появления проблемы наблюдались периодические зависания, странные звуки или было физическое воздействие (уронили, потрясли, перегрелся).
5. Неправильно или неплотно подключили HDD.
6. Недостаток питания. Несмотря на то, что винчестеры потребляют мало мощности, плохой или полуживой блок питания может нарушать его работу.

Перед тем как переходить к исправлению проблемы убедитесь, что накопитель виден в БИОС. Если его там нет, то проверьте подключение и при необходимости замените SATA кабель. Иногда достаточно протереть контактные дорожки ластиком. Если это не помогло, то скорее всего он неисправен и подлежит замене.

Изменение приоритета загрузки

Проще всего восстановить порядок загрузки можно отключив от компьютера второстепенные устройства (внешние HDD, флешки, карты памяти и прочие).

Но есть еще и ручной способ.

1. Зайдите в BIOS и найдите параметр «Boot Option» или аналогичный.
2. Установите на первое место накопитель с Windows и сохраните изменения.

Восстановление файловой системы и загрузчика

Это самый безопасный способ, который может помочь в восстановлении работы ПК. Обзаведитесь загрузочной флешкой, LiveCD или WinPE. Буду показывать на примере WinPE (мне нравится сборка от Sergei Strelec ). Принцип записи этой сборки на флешку тот же, что и с Windows, поэтому проблем возникнуть не должно.

1. Загружаете с накопителя ОС и запускаете командную строку (найти ее можно в Пуске).
2. Вводите chkdsk C: /f /r – где под буквой «C» подразумевается раздел с операционной системой, которая вышла из строя. Жмете «Enter». Начнется автоматическая проверка и исправление ошибок.
3. Теперь выполните другую команду — bcdboot C:windows. Она восстановит загрузочную область.

Закрываем все окна и загружаемся в обычном режиме. Все должно работать.

Настройка Биос

Иногда, изменение настроек Биос влечет за собой появления различных ошибок. Ситуация налаживается следующим образом.

1. Сбросом параметров. Воспользуйтесь опцией «Optimized Defaults» или аналогичной.
2. Найдите опцию, отвечающую за режим работы накопителя. Обычно это «Sata Mode» ,«Sata Type». Установите значение «AHCI». Если и так стоит «AHCI», то измените на «IDE». Сохраните изменения и перезапуститесь.
3. Если проблема возникла после обновления BIOS. То установите старую версию. Загружается с официального сайта материнской платы или ноутбука. Иногда, наоборот, помогает обновление Попробуйте оба варианта.

Если настройки не сохраняются, то замените батарею питания, скорее всего она отжила свое. Производить замену желательно 3-5 лет.

Разбираемся с жестким диском

Рассмотрим несколько типичных проблем и попробуем их исправить.

1. Проверьте подключение носителя. Особенно, если до появления сбоя проводились какие-либо работы внутри корпуса ПК. Также можно подключить его к другому порту.
2. Замените SATA кабель.
3. Удостоверьтесь, что винчестер исправен. Проведите сканирование через «Victoria» или «MHDD». Иногда, казалось бы, нормальный HDD с хорошим смартом и результатами тестирования все равно может быть неисправным. Подтверждать это будет невозможность установить Windows, зависания и сбои приложений.

Если и это не избавило от ошибки «A disk read error occurred», то напоследок предложу еще несколько вариантов. Маловероятно, что они помогут, но попробовать стоит.

Дополнительные способы

Вот еще несколько способов, которые помогли некоторым пользователям. Были взять с форумов, комментариев и видео.

1. Протестируйте оперативную память. Предварительно очистив их от пыли. При обнаружении неисправности замените битые планки. Также если установлено два или более модулей ОЗУ, попробуйте поменять их местами или вынуть все, кроме одного.
2. Проведите дефрагментацию. Скептически отношусь к этому пункту.
3. Переустановите ОС. Возможно, используется «кривая» или поврежденная сборка.
4. Проведите сканирование на вирусы.
5. Редко виновниками становится материнская плата (в том числе SATA разъем) или блок питания. Поэтому протестируйте HDD на другом компьютере.
6. Бывает, что системный диск с операционкой пропадает (удаляется) сам по себе. Решается восстановлением раздела с помощью специальных программ, например, «Acronis Disk Director» или созданием нового раздела (при этом придется заново устанавливать ОС). Если это повторяется часто, то желательно заменить такой накопитель.
7. Посмотрите на контакты на обратной стороне платы (нужно открутить отверткой), возможно, произошло окисление. Почистите их и прикрутите плату обратно. Выполняйте эту процедуру осторожно и только в крайнем случае, когда нечего терять.

Напишите в комментариях, если возникли сложности. Буду рад помочь.

Источник

Время на прочтение
17 мин

Количество просмотров 70K

Приветствую, Хабр!

В этой статье я постараюсь разжевать, что делать с дампами в Java, как понять причину или приблизиться к причине возникновения OOM, посмотреть на инструменты для анализа дампов, инструмент (один, да) для мониторинга хипа, и вообще вникнуть в это дело для общего развития. Исследуются такие инструменты, как JVisualVM (рассмотрю некоторые плагины к нему и OQL Console), Eclipse Memory Analyzing Tool.
Очень много понаписал, но надеюсь, что всё только по делу

Предыстория

Для начала нужно понять, как возникает OOM. Кому-то это может быть ещё неизвестно.
Представьте себе, что есть какой-то верхний предел занимаемой оперативки для приложения. Пусть это будет гигабайт ОЗУ.
Само по себе возникновение OOM в каком-то из потоков ещё не означает, что именно этот поток «выжрал» всю свободную память, да и вообще не означает, что именно тот кусок кода, который привёл к OOM, виноват в этом.
Вполне нормальна ситуация, когда какой-то поток чем-то занимался, поедая память, «дозанимался» этим до состояния «ещё немного, и я лопну», и завершил выполнение, приостановившись. А в это время какой-то другой поток решил запросить для своей маленькой работы ещё немного памяти, сборщик мусора попыжылся, конечно, но мусора уже в памяти не нашёл. В этом случае как раз и возникает OOM, не связанный с источником проблемы, когда стектрейс покажет совсем не того виновника падения приложения.

Есть и другой вариант. Около недели я исследовал, как улучшить жизнь парочки наших приложений, чтобы они перестали себя нестабильно вести. И ещё недельку-две потратил на то, чтобы привести их в порядок. В общей сложности пара недель времени, которые растянулись на полтора месяца, ведь занимался я не только этими проблемами.
Из найденного: сторонняя библиотека, и, конечно же, некоторые неучтённые вещи в вызовах хранимых процедур.
В одном приложении симптомы были следующие: в зависимости от нагрузки на сервис, оно могло упасть через сутки, а могло через двое. Если помониторить состояние памяти, то было видно, что приложение постепенно набирало «размер», и в определённый момент просто ложилось.
С другим приложением несколько интереснее. Оно может вести себя хорошо длительный срок, а могло перестать отвечать минут через 10 после перезагрузки, или вдруг внезапно упасть, сожрав всю свободную память (это я уже сейчас вижу, наблюдая за ним). А после обновления версии, когда была изменена и версия Tomcat с 7й до 8й, и JRE, оно вдруг в одну из пятниц (проработав вменяемо до этого ни много ни мало — 2 недели) начало творить такие вещи, что стыдно признаваться в этом.

В обоих историях очень полезны оказались дампы, благодаря им удалось отыскать все причины падений, подружившись с такими инструментами, как JVisualVM (буду называть его JVVM), Eclipse Memory Analyzing Tool (MAT) и языком OQL (может быть я не умею его правильно готовить в MAT, но мне оказалось легче подружиться с реализацией OQL именно в JVVM).
Ещё вам понадобится свободная оперативка для того, чтобы было куда загружать дампы. Её объём должен быть соизмерим с размером открываемого дампа.

Начало

Итак, начну потихоньку раскрывать карты, и начну именно с JVVM.

Этот инструмент в соединении с jstatd и jmx позволяет удалённо наблюдать за жизнью приложения на сервере: Heap, процессор, PermGen, количество потоков и классов, активность потоков, позволяет проводить профилирование.
Также JVVM расширяем, и я не преминул воспользоваться этой возможностью, установив некоторые плагины, которые позволили куда больше вещей, например, следить и взаимодействать с MBean’ами, наблюдать за деталями хипа, вести длительное наблюдение за приложением, держа в «голове» куда больший период метрик, чем предоставляемый вкладкой Monitor час.

Вот так выглядит набор установленных плагинов.
Visual GC (VGC) позволяет видеть метрики, связанные с хипом.

Предпосылки

Итак, случилось сразу две вещи:
1) после перехода на более новые библиотеки/томкеты/джавы в одну из пятниц приложение, которое я уже долгое время веду, вдруг стало вести себя из рук вон плохо спустя две недели после выставления.
2) мне на рефакторинг отдали проект, который тоже вёл себя до некоторого времени не очень хорошо.

Я уже не помню, в каком точно порядке произошли эти события, но после «чёрной пятницы» я решил наконец-то разобраться с дампами памяти детальнее, чтобы это более не было для меня чёрным ящиком. Предупреждаю, что какие-то детали я мог уже запамятовать.

По первому случаю симптомы были такие: все потоки, отвественные за обработку запросов, выжраны, на базу данных открыто всего 11 соединений, и те не сказать, что используются, база говорила, что они в состоянии recv sleep, то есть ожидают, когда же их начнут использовать.
После перезагрузки приложение оживало, но прожить могло недолго, вечером той же пятницы жило дольше всего, но уже после окончания рабочего дня таки снова свалилось. Картина всегда была одинаковой: 11 соединений к базе, и лишь один, вроде бы, что-то делает.
Память, кстати, была на минимуме. Сказать, что OOM привёл меня к поиску причин, не могу, однако полученные знания при поиске причин позволили начать активную борьбу с OOM.

Когда я открыл дамп в JVVM, из него было сложно что-либо понять.

Подсознание подсказывало, что причина где-то в работе с базой.
Поиск среди классов сказал мне, что в памяти аж 29 DataSource, хотя должно быть всего 7.

Это и дало мне точку, от которой можно было бы оттолкнуться, начать распутывать клубок.

OQL

Сидеть переклацывать в просмотровщике все эти объекты было некогда, и моё внимание наконец-то привлекла вкладка OQL Console, я подумал, что вот он, момент истины — я или начну использовать её на полную катушку, или так и забью на всё это.

Прежде, чем начать, конечно же был задан вопрос гуглу, и он любезно предоставил шпаргалку (cheat sheet) по использованию OQL в JVVM: http://visualvm.java.net/oqlhelp.html

Сначала обилие сжатой информации привело меня в уныние, но после применения гугл-фу на свет таки появился вот такой OQL-запрос:

select {instance: x, uri: x.url.toString(), connPool: x.connectionPool}
from org.apache.tomcat.dbcp.dbcp2.BasicDataSource x
where x.url != null
&& x.url.toString() == "jdbc:sybase:Tds:айпишник:порт/базаДанных"

Это уже исправленная и дополненная, финальная версия этого запроса
Результат можно увидеть на скриншоте:

После нажатия на BasicDataSource#7 мы попадаем на нужный объект во вкладке Instances:

Через некоторое время до меня дошло, что есть одно несхождение с конфигурацией, указанной в теге Resource в томкете, в файле /conf/context.xml. Ведь в дампе параметр maxTotal имеет значение 8, в то время, как мы указывали maxActive равным 20…

Тут-то до меня и начало доходить, что приложение жило с неправильной конфигурацией пула соединений все эти две недели!
Для краткости напишу тут, что в случае, если вы используете Tomcat и в качестве пула соединений — DBCP, то в 7м томкете используется DBCP версии 1.4, а в 8м томкете — уже DBCP 2.0, в котором, как я потом выяснил, решили переименовать некоторые параметры! А про maxTotal вообще на главной странице сайта написано
http://commons.apache.org/proper/commons-dbcp/
«Users should also be aware that some configuration options (e.g. maxActive to maxTotal) have been renamed to align them with the new names used by Commons Pool 2.»

Причины

Обозвал их по всякому, успокоился, и решил разобраться.
Как оказалось, класс BasicDataSourceFactory просто напросто получает этот самый Resource, смотрит, есть ли нужные ему параметры, и забирает их в порождаемый объект BasicDataSource, молча игнорируя напрочь всё, что его не интересует.
Так и получилось, что они переименовали самые весёлые параметры, maxActive => maxTotal, maxWait => maxWaitMillis, removeAbandoned => removeAbandonedOnBorrow & removeAbandonedOnMaintenance.
По умолчанию maxTotal, как и ранее, равен 8; removeAbandonedOnBorrow, removeAbandonedOnMaintenance = false, maxWaitMillis устанавливается в значение «ждать вечно».
Получилось, что пул оказался сконфигурирован с минимальным количеством соединений; в случае, если заканчиваются свободные соединения — приложение молча ждёт, когда они освободятся; и добивает всё молчанка в логах по поводу «заброшенных» соединений — то, что могло бы сразу показать, в каком именно месте

программист мудак

код хватает соединение, но не отдаёт его обратно по окончанию своей работы.
Это сейчас вся мозаика сложилась быстро, а добывались эти знания дольше.

«Так быть не должно», решил я, и запилил патчик (https://issues.apache.org/jira/browse/DBCP-435, выразился в http://svn.apache.org/viewvc/commons/proper/dbcp/tags/DBCP_2_1/src/main/java/org/apache/commons/dbcp2/BasicDataSourceFactory.java?view=markup ), патч был принят и вошёл в версию DBCP 2.1. Когда и если Tomcat 8 обновит версию DBCP до 2.1+, думаю, что админам откроются многие тайны про их конфигурации Resource

По поводу этого происшествия мне лишь осталось рассказать ещё одну деталь — какого чёрта в дампе было аж 29 DataSource’ов вместо всего 7 штук. Разгадка кроется в банальной арифметике, 7*4=28 +1=29.

<ResourceLink name="jdbc/MyDB" global="jdbc/MyDB" type="javax.sql.DataSource"/>

После этого всё стало ясно: 11 соединений было потому, что в одном, активном DataSource было съедено 8 соединений (maxTotal = 8), и ещё по minIdle=1 в трёх других неиспользуемых DataSource-копиях.

В ту пятницу мы откатились на Tomcat 7, который лежал рядышком, и ждал, когда от него избавятся, это дало время спокойно во всём разобраться.
Плюс позже, уже на TC7, обнаружилась утечка соединений, всё благодаря removeAbandoned+logAbandoned. DBCP радостно сообщил в логфайл catalina.log о том, что

"org.apache.tomcat.dbcp.dbcp.AbandonedTrace$AbandonedObjectException: DBCP object created 2015-02-10 09:34:20 by the following code was never closed:
	at org.apache.tomcat.dbcp.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:139)
	at org.apache.tomcat.dbcp.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:81)
	at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
	at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
	at наш.пакет.СуперКласс.getConnection(СуперКласс.java:100500)
	at наш.пакет.СуперКласс.плохойПлохойМетод(СуперКласс.java:100800)
	at наш.пакет.СуперКласс.вполнеВменяемыйМетод2(СуперКласс.java:100700)
	at наш.пакет.СуперКласс.вполнеВменяемыйМетод1(СуперКласс.java:100600)
	ещё куча строк..."

Вот этот вот плохойПлохойМетод имеет в сигнатуре Connection con, но внутри была конструкция «con = getConnection();», которая и стала камнем преткновения. СуперКласс вызывается редко, поэтому на него и не обращали внимания так долго. Плюс к этому, вызовы происходили, я так понимаю, не во время рабочего дня, так что даже если что-то и подвисало, то никому уже не было дела до этого. А в ТуСамуюПятницу просто звёзды сошлись, начальнику департамента заказчика понадобилось посмотреть кое-что

Приложение №2

Что же касается «события №2» — мне отдали приложение на рефакторинг, и оно на серверах тут же вздумало упасть.
Дампы попали уже ко мне, и я решил попробовать поковырять и их тоже.
Открыл дамп в JVVM, и «чё-то приуныл»:

Что можно понять из Object[], да ещё и в таком количестве?
( Опытный человек, конечно же, увидел уже причину, правда? )

Так у меня зародилась мысль «ну неужели никто ранее не занимался этим, ведь наверняка уже есть готовый инструмент!». Так я наткнулся на этот вопрос на StackOverflow: http://stackoverflow.com/questions/2064427/recommendations-for-a-heap-analysis-tool-for-java.
Посмотрев предложенные варианты, я решил остановиться на MAT, надо было попробовать хоть что-то, а это открытый проект, да ещё и с куда бОльшим количеством голосов, чем у остальных пунктов.

Eclipse Memory Analyzing Tool

Итак, MAT.
Рекомендую скачивать последнюю версию Eclipse, и устанавливать MAT туда, потому как самостоятельная версия MAT ведёт себя плохо, там какая-то чертовщина с диалогами, в них не видно содержимого в полях. Быть может кто-то подскажет в комментариях, чего ему не хватает, но я решил проблему, установив MAT в Eclipse.

Открыв дамп в MAT я запросил выполнение Leak Suspects Report.


Удивлению не было предела, честно говоря.

1.2 гига весят соединения в базу.

Каждое соединение весит от 17 до 81 мегабайта.

Ну и ещё «немного» сам пул.
Визуализировать проблему помог отчёт Dominator Tree:

Причиной всех падений оказались километры SQLWarning’ов, база настойчиво пыталась дать понять, что «010SK: Database cannot set connection option SET_READONLY_TRUE.», а пул соединений BoneCP не вычищает SQLWarning’и после освобождения и возврата соединений в пул (может быть это где-то можно сконфигурировать? Подскажите, если кто знает).
Гугл сказал, что такая проблема с Sybase ASE известна ещё с 2004 года: https://forum.hibernate.org/viewtopic.php?f=1&t=932731
Если вкратце, то «Sybase ASE doesn’t require any optimizations, therefore setReadOnly() produces a SQLWarning.», и указанные решения всё ещё работают.
Однако это не совсем решение проблемы, потому как решение проблемы — это когда при возврате соединения в пул все уведомления базы очищаются в силу того, что они уже никогда никому не понадобятся.
И DBCP таки умеет делать это: http://svn.apache.org/viewvc/commons/proper/dbcp/tags/DBCP_1_4/src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java?view=markup, метод passivateObject(Object obj), в строке 687 можно увидеть conn.clearWarnings();, этот вызов и спасает от километров SQLWarning’ов в памяти.
Об этом я узнал из тикета: https://issues.apache.org/jira/browse/DBCP-102
Также мне подсказали про вот такой тикет в багтрекере: https://issues.apache.org/jira/browse/DBCP-234, но он касается уже версии DBCP 2.0.

В итоге я перевёл приложение на DBCP (пусть и версии 1.4). Пусть нагрузка на сервис и немаленькая (от 800 до 2к запросов в минуту), но всё же приложение ведёт себя хорошо, а это главное. И правильно сделал, потому как BoneCP уже пять месяцев не поддерживается, правда, ему на смену пришёл HikariCP. Нужно будет посмотреть, как дела в его исходниках…

Сражаемся с OOM

Впечатлившись тем, как MAT мне всё разложил по полочкам, я решил не забрасывать этот действенный инструмент, и позже он мне пригодился, потому как в первом приложении ещё остались всяческие «неучтёнки» — неучтённые вещи в коде приложения или коде хранимых процедур, которые иногда приводят к тому, что приложение склеивает ласты. Я их отлавливаю до сих пор.

Вооружившись обоими инструментами, я принялся ковырять каждый присланный дамп в поисках причин падения по OOM.
Как правило все OOM приводили меня к TaskThread.

И если нажать на надпись See stacktrace, то да, это будет как раз банальный случай, когда какой-то поток вдруг внезапно упал при попытке отмаршалить результат своей работы.

Однако здесь ничто не указывает на причину возникновения OOM, здесь лишь результат. Найти причину мне пока-что, в силу незнания всей магии OQL в MAT, помогает именно JVVM.
Загружаем дамп там, и пытаемся отыскать причину!

Искать мне следует, конечно же, именно вещи, связанные с базой данных, а посему попробуем сначала посмотреть, есть ли в памяти Statement’ы.

Два SybCallableStatement, и один SybPreparedStatement.
Думаю, что дело усложнится, если Statement’ов будет куда больше, но немного подрихтовав один из следующих запросов, указав в where нужные условия, думаю, всё у Вас получится. Плюс, конечно же, стоит хорошенько посмотреть в MAT, что за результаты пытается отмаршалить поток, какой объект, и станет понятнее, какой именно из Statement’ов необходимо искать.

select {
    instance: x,
    stmtQuery: x._query.toString(),
    params: map(x._paramMgr._params, function(obj1) {
            if (obj1 != null) {
                if (obj1._parameterAsAString != null) {
                    return '''+obj1._parameterAsAString.toString()+''';
                } else {
                    return "null";
                }
            } else {
                return "null";
            }
        })
    }
from com.sybase.jdbc4.jdbc.SybCallableStatement x
where x._query != null

Не то, это «внутренние» вызовы.

select {
    instance: x,
    stmtQuery: x._query.toString(),
    params: map(x._paramMgr._params, function(obj1) {
            if (obj1 != null) {
                if (obj1._parameterAsAString != null) {
                    return '''+obj1._parameterAsAString.toString()+''';
                } else {
                    return "null";
                }
            } else {
                return "null";
            }
        })
    }
from com.sybase.jdbc4.jdbc.SybPreparedStatement x
where x._query != null

А вот и дичь!
Для чистоты эксперимента можно кинуть такой же запрос в любимой БД-IDE, и он будет очень долго отрабатывать, а если покопаться в недрах хранимки, то будет понятно, что там просто из базы, которая нам не принадлежит, выбирается 2 миллиона строк по такому запросу с такими параметрами. Эти два миллиона даже влазят в память приложения, но вот попытка отмаршалить результат становится фатальной для приложения. Такое себе харакири.
При этом GC старательно убирает все улики, но не спасло его это, всё же источник остался в памяти, и он будет наказан.

Почему-то после всего этого рассказа почувствовал себя тем ещё неудачником.

Прощание

Вот и закончилось моё повествование, надеюсь, Вам понравилось
Хотел бы выразить благодарность своему начальнику, он дал мне время во всём этом разобраться. Считаю эти новые знания очень полезными.
Спасибо девушкам из Scorini за неизменно вкусный кофе, но они не прочтут этих слов благодарности — я даже сомневаюсь, что они знают о существовании Хабрахабра
Хотелось бы увидеть в комментариях ещё больше полезной инфы и дополнений, буду очень благодарен.

Думаю, самое время почитать документацию к MAT…

UPD1: Да, совсем забыл рассказать про такие полезные вещи, как создание дампов памяти.
docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/clopts.html#gbzrr
Опции
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/disk2/dumps
весьма полезны для генерации дампов в момент падения приложения по OutOfMemoryError,
а также существует возможность снять дамп памяти с приложения «наживо», посреди его работы.
Для этого существует утилита jmap.
Пример вызова для винды:
«C:installPSToolsPsExec.exe» -s «C:Program FilesJavajdk1.7.0_55binjmap.exe» -dump:live,format=b,file=C:dump.hprof 3440
последний параметр — это PID java-процесса. Приложение PsExec из набора PSTools позволяет запускать другие приложения с правами системы, для этого служит ключ «-s». Опция live полезна, чтобы перед сохранением дампа вызвать GC, очистив память от мусора. В случае, когда возникает OOM, чистить память незачем, там уже не осталось мусора, так что не ищите, как можно установить опцию live в случае возникновения OOM.

UPD2 (2015-10-28) | Случай номер два три
(Было принято решение дописать это сюда как апдейт, а не пилить новую статью о том же самом):
Ещё один интересный случай, но уже с Оракловой базой.
Один из проектов использует фичу с XML, проводит поиски по содержимому сохранённого XML-документа. В общем, этот проект иногда давал о себе знать тем, что вдруг внезапно один из инстансов переставал подавать признаки жизни.
Почуяв «хороший» случай потренироваться

на кошках

, я решил посмотреть его дампы памяти.

Первое, что я увидел, было «у вас тут много коннектов в памяти осталось». 21к!!! И какой-то интересный oracle.xdb.XMLType тоже давал жару. «Но это же Оракл!», вертелось у меня в голове. Забегая вперёд скажу что таки да, он виноват.

Итак, видим кучу T4CConnection, которые лежат в HashMap$Entry. Обратил внимание сразу, что вроде бы и SoftHashMap, что, вроде как, должно означать, что оно не должно вырастать до таких размеров. Но результат видите и сами — 50-60 килобайт в коннекте, и их реально МНОГО.

Посмотрев, что собой представляют HashMap$Entry — увидел, что примерно картина одинакова, всё связано с SoftHashMap, с Оракловыми коннектами.

Что, собственно, подтверждалось такой картинкой. HashMap$Entry было просто море, и они более-менее сакуммулировались внутри oracle.xdb.SoftHashMap.
В следующем дампе картина была примерно такой же. По Dominator Tree было видно, что внутри каждого Entry находится тяжёлый такой BinXmlProcessorImpl.

-=-=-
Если учесть, что я в тот момент был не силён в том, что такое xdb, и как он связан с XML, то, несколько растерявшись, я решил, что надо бы погуглить, быть может кто-то уже в курсе, что со всем этим нужно делать. И чутьё не обмануло, по запросу «oracle.xdb.SoftHashMap T4CConnection» нашлось
раз piotr.bzdyl.net/2014/07/memory-leak-in-oracle-softhashmap.html
и два leakfromjavaheap.blogspot.com/2014/02/memory-leak-detection-in-real-life.html
Утвердившись, что тут всё-таки косяк у Оракла, дело оставалось за малым.
Попросил администратора БД посмотреть информацию по обнаруженной проблеме:

xxx: Ключевые слова: SoftHashMap XMLType
yyy: Bug 17537657 Memory leak from XDB in oracle.xdb.SoftHashMap
yyy: The fix for 17537657 is first included in
12.2 (Future Release)
12.1.0.2 (Server Patch Set)
12.1.0.1.4 Database Patch Set Update
12.1.0.1 Patch 11 on Windows Platforms
yyy: нда. Описание
Description
When calling either getDocument() using the thin driver, or getBinXMLStream()
using any driver, memory leaks occur in the oracle.xdb.SoftHashMap class.
BinXMLProcessorImpl classes accumulate in this SoftHashMap, but are never
removed.
xxx: Всё так и есть

Вот описание фикса: updates.oracle.com/Orion/Services/download?type=readme&aru=18629243 (для доступа требуется учётка в Оракл).
-=-=-
После применения фикса инстансы нашего приложения живут уже месяц, и пока без эксцессов. *постучал по дереву* *поплевал через левое плечо*
Успехов Вам в поисках!

• Причины появления дисфункции
• Как исправить ошибку «Out of memory»
• Заключение