|
|
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Есть старый сервер с Oracle на RHEL4 (2 CPU, по 4 ядра). К серверу смонтирован сетевой диск по iscsi, на который сохраняются бэкапы. Сегодня по какой-то причине перегрузился. Сейчас сервер загрузился и работает, но в нем наблюдается какая-то задумчивость - на ввод любой команды он реагирует задержкой, иногда в 5-10 секунд. В top какой-то заметной загрузки CPU я не вижу, обычно CPU загружен не более 20%. Правда load average более 70, но для данного сервера (8 ядер) это, мне кажется, нормально. После перезагрузки сервера база данных запустилась, но тоже отличалась некоторой задумчивостью. Затем в логах появилось сообщение "kernel: tnslsnr[23700]: segfault at 0000000000000018 rip 000000344af6889d rsp 0000007fbfff8ff0 error 4" и сейчас БД недоступна. Подскажите, куда смотреть? Сейчас я думаю сделать shutdown базы, перегрузить сервер и посмотреть лог загрузки. ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2016, 17:18 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. Для Вашего сервера нормально 16 Вини-ПухЭто жжж... не спроста! Смотреть: 1) memtest (выбрать при загрузке) 2) /var/log/messages 3) dmesg 4) смотреть статистику при проблемах(RHEL4 под рукой нет, поэтому некоторые ключи могут не взлететь): sar -W 10 10 sar -d 10 10 sar -q 10 10 sar -u 10 10 5)cat /proc/meminfo 6) cat /proc/cpuinfo ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2016, 17:53 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
До этого сервер загрузился, но пытался смонтировать iscsi-тома до того, как поднялась сеть (безуспешно), так что я закомментировал эти тома в /etc/fstab и затем смонтировал их вручную. Теперь погасил базу, перегрузил сервер и никаких тормозов пока не замечаю. load average около единицы. В /var/log/messages есть "Buffer I/O error on device sdb", но /dev/sdb это не том, это access-устройство на СХД. Других ошибок в логе и в dmesg я не увидел. sar у меня отсутствует, буду искать старые RPM. А на что именно смотреть в meminfo и cpuinfo? Вроде бы ничего проблемного там не вижу. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2016, 18:12 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Вообщем пока выключил вообще iscsi, но проблемы остаются. Как только запускаю сервер, работающий с БД, load average на сервере начинает расти, дорос до 70. Останавливаю сервер и load average понемногу снижается, сейчас около 30. При этом top показывает, что большой процент занимает wait (50-60%). Скорее всего это ввод/вывод, но пока подробнее посмотреть не могу, iotop на сервере не установлен, а готовый бинарник нигде пока найти не могу. В логах чисто, никаких ошибок не вижу. Это может быть Oracle, который восстанавливает данные после прошлого некорректного выключения? В /opt/oracle/admin/bm/bdump/alert_bm.log есть такие записи: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2016, 16:37 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
авторsar у меня отсутствует, буду искать старые RPM. Код: plsql 1. 2. Что - нибудь менялось? Например параметры Oracle, или нагрузка У вас всго 4Gb памяти Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. показывет что особой нагрузки на запись у Вас нет в top какие процессы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2016, 16:48 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Сейчас нагрузка упала (load average: 0.04, 0.04, 0.01), поэтому измерения наверное будут не показательны. Когда нагрузка была высокой, в top часто был oracle. Сейчас особо ничего нет. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. Никакие параметры или настройки не менялись. Вообще у меня есть предположение, что нагрузка связана с тем, что Oracle восстанавливал или откатывал транзакции с журналов, которые не были выполнены из-за аварийного отключения сервера. А сейчас все восстановил и далее работать будет уже обычным образом. Такое возможно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2016, 19:57 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Alibek B., о восстановлении - там же, в alert; и, возможно fsck проверяла iscsi ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2016, 21:15 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Разработчики подключились, но пока ничего криминального не нашли. Сейчас приложение и база данных работают без каких-либо проблем, в том числе и массовые операции, которые штатно выполняются пару часов. Но когда я включаю сервер приложений в боевую нагрузку, нагрузка на сервер БД начинает расти и через несколько часов она доходит до запредельных значений (70-100), все начинает тормозить и через какое-то время падает база (обычно с ошибкой segfault падает TNS-листенер). В боевой нагрузке идет большое количество insert в три таблицы, в двух из которых порядка 300М записей и в третьей порядка 20М записей. Может быть повышение нагрузки на сервер связано с тем, что повреждены данные в dbf-файлах или запортилась статистика, из-за чего работа с этими тремя таблицами происходит значительно медленнее обычного? Или причина в чем-то другом? Завтра я вместе с разработчиками думаю на некоторое время включить рабочую нагрузку и поснимать статистику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2016, 19:48 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Alibek B.Разработчики подключились, но пока ничего криминального не нашли. Сейчас приложение и база данных работают без каких-либо проблем, в том числе и массовые операции, которые штатно выполняются пару часов. Но когда я включаю сервер приложений в боевую нагрузку, нагрузка на сервер БД начинает расти и через несколько часов она доходит до запредельных значений (70-100), все начинает тормозить и через какое-то время падает база (обычно с ошибкой segfault падает TNS-листенер). В боевой нагрузке идет большое количество insert в три таблицы, в двух из которых порядка 300М записей и в третьей порядка 20М записей. Может быть повышение нагрузки на сервер связано с тем, что повреждены данные в dbf-файлах или запортилась статистика, из-за чего работа с этими тремя таблицами происходит значительно медленнее обычного? Или причина в чем-то другом? Завтра я вместе с разработчиками думаю на некоторое время включить рабочую нагрузку и поснимать статистику. Обычно такое поведение связана с началом swapping на ОС ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 01:57 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Ни ОЗУ, ни своп не менялись уже несколько лет, но ранее такого поведения не было. Но за подсказку спасибо, сегодня понаблюдаю за своппингом под нагрузкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 09:50 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
надо проверить батарейку на RAID-контроллере. Похоже она отказала и отключился кеш на запись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 11:51 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Спасибо за наводку, проверю. Выглядит вполне возможным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 12:33 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Мутагеннадо проверить батарейку на RAID-контроллере. Похоже она отказала и отключился кеш на запись Хорошая была версия, к сожалению с батарейкой все в порядке. Буду смотреть дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 14:27 |
|
||
|
Тормозит сервер
|
|||
|---|---|---|---|
|
#18+
Вообщем разработчики разобрались с проблемой. Они обнаружили, что после сервер приложений записи определенного типа обрабатывает существенно медленнее обычных записей. Я отключил отправку записей этого типа на сервер приложений (они несущественны) и теперь все работает штатным образом. С этими записями система без каких-либо проблем работала пару лет и для меня несколько непонятно, почему проблема вылезла именно сейчас, тем более что записи эти различаются на прикладном уровне, а в базе данных он хранятся в одной таблице с остальными записями. Но причину выяснить разработчики не смогли и предположили, что это звезды так сошлись — совпало сразу несколько условий. Вообщем проблема была не в БД и топик можно закрывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2016, 16:54 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39376577&tid=1886731]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 525ms |

| 0 / 0 |
