|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Добрый день! Есть 2 тестовых сервера. По софту абсолютно одинаковые. На обоих стоит RHEL5 и IDS 11.50.FC5W3. Поднята синхронная репликация HA. Серверы соединены друг с другом по сети 1 Гб через свитч. Кроме этих 2х серверов свитч никто не использует. Репликация настроена следующим образом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Периодически HDR рвется, и в логах появляются следующие записи Primary: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Secondary: Код: plaintext 1. 2. 3. 4. 5. 6.
Примечательно, что оба раза (в 4:08 и в 4:17) HDR оборвалась во время выполнения L0 бекапа (с 03:30 по 04:21). Кроме того, с 03:30 по 05:00 работал еще один тяжелый процесс, который массово удалял записи из таблиц. Удалял кусками по 1000 шт. Всего удалено было несколько млн строк. Возможно, здесь есть какая-то связь? Подскажите, пожалуйста, в чем может быть проблема, куда копать? Насколько я понял, кто-то из серверов вовремя не ответил на ping. Но почему? Логи с обеих серверов приложил. Там зафиксированы 2 падения. Кстати, после падений репликация сама восстанавливалась. П.С. Приложил onconfig. Если у кого-нибудь будут замечания, любые комментарии к настройкам - буду очень признателен. Сервер БД смешанный. Основная задача OLTP. Но присутствуют и ежедневные тяжелые запросы с группировками и JOIN'ами, полные сканирования, массовые удаления. Но основное - инсерты по 1 записи, выборки и апдейты по ключевому полю. База в режиме Unbuffered Logging. Чанки - coocked файлы. ОС RHEL 5 x64. Работает только IDS. Под него выделены 22 Гб ОП. С наступающим! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 12:35 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Попробуйте увеличить DRTIMEOUT. С уважением, Виктор ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 12:54 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
victor16Попробуйте увеличить DRTIMEOUT. С уважением, Виктор Спасибо, попробую. Но неужели 30ти секунд ему не хватает? Ведь репликация должна рваться, если в течение 30*4 = 120 секунд не было ответа на ping. Чем так сильно был занят сервер, чтобы 2 минуты молчать? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 13:08 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Посмотрите время выполнения контрольных точек, а также системное время на обоих серверах. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 13:26 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
victor16, В точку. Времена работы КТ в моменты падения 131 и 121 сек. соответственно. Т.е. больше чем DRTIMEOUT x 4. Уменьшу CKPTINTVL и увеличу DRTIMEOUT. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 14:03 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS AdminВремена работы КТ в моменты падения 131 и 121 сек. соответственно. Т.е. больше чем DRTIMEOUT x 4. Возможно, что это следствие , а не причина. Если бы у вас попадались ранее и другие похожие КТ, но длительностью чуть меньше (типа 80-110 сек), то тогда может это и было бы причиной. Кстати, а длительности КТ в 40-60 сек вас не сильно волнуют ? IDS AdminУменьшу CKPTINTVL и увеличу DRTIMEOUT. Не обязательно уменьшать CKPTINTVL - будет много непроизводительной работы и общая производительность системы может упасть. Есть и другие способы уменьшения длительности КТ. P.S. Внимательнее посмотрел и таки увидел КТ длительностью близкой к критичной - 87 и 95. Похоже, что все таки это причина. Так что увеличивайте интервал для нагруженных систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2009, 18:42 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
vasilis Не обязательно уменьшать CKPTINTVL - будет много непроизводительной работы и общая производительность системы может упасть. Есть и другие способы уменьшения длительности КТ. А можно чуть подробнеe? Конечно, лучше уменьшить длительность КТ. Уменьшать кол-во буферов не хочется, уменьшится % cached и будет лишний IO. Чанки с данными лежат на 10м рейде из 24 дисков дисков (15к, SAS). 256 МБ на write-back кеш рейд-контроллера. (кстати, логические журналы лежат на других дисках и рейд-контроллере). Сдвинуть окно lru dirty? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2009, 14:32 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Заметил, что время КТ увеличивается примерно раз в 5, когда КТ делается во время ontape -r -L 0. Насколько я понимаю, чтобы бэкап был "непротиворечивым", начальные образы грязных страниц, еще не попавших на ленту, должны на нее попасть во время КТ. Т.е. IDS во время КТ надо не просто скинуть страницу из буферов на диск, а еще и считать ее образ "до изменения" и записать его на ленту. Из-за этого и увеличивается время КТ. Поправьте, пожалуйста, если я не прав. Можно с этим что-то сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2009, 14:53 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS Adminvasilis Не обязательно уменьшать CKPTINTVL - будет много непроизводительной работы и общая производительность системы может упасть. Есть и другие способы уменьшения длительности КТ. А можно чуть подробнеe? Конечно, лучше уменьшить длительность КТ. Уменьшать кол-во буферов не хочется, уменьшится % cached и будет лишний IO. Чанки с данными лежат на 10м рейде из 24 дисков дисков (15к, SAS). 256 МБ на write-back кеш рейд-контроллера. (кстати, логические журналы лежат на других дисках и рейд-контроллере). Сдвинуть окно lru dirty? Чтобы давать конкретные рекомендации нужна дополнительная статистика. К тому же, у вас включено AUTO_LRU_TUNING 1 и довольно большие буфера. Поэтому для начала нужно собрать информацию, переключить на ручное управление (оно для зеро-админов :) и потом потихоньку пробовать по одному изменению. Посмотри внимательно обсуждение "длинный чекпойнт" - http://sql.ru/forum/actualthread.aspx?tid=66974&pg=-1&hl=%f3%ec%e5%ed%fc%f8%e8%f2%fc+%e2%f0%e5%ec%ff Оно было достаточно интересным и длинным. Можно еще и это посмотреть http://sql.ru/forum/actualthread.aspx?tid=66632&hl=%f3%ec%e5%ed%fc%f8%e8%f2%fc+%e2%f0%e5%ec%ff ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2009, 15:45 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
vasilis, Спасибо, почитал эти ветки. Начал проверять, на что тратится время при выполнении КТ и одновременном бекапе L0. Судя по sar -d из ~40 секунд длительности КТ интенсивная запись на диски с данными идет лишь ~5 секунд в конце КТ. На что может уходить остальное время в начале выполнения КТ? Еще раз отмечу, это происходит только при работает ontape -r. Что-то мне подсказывает, что придется 20 Гб буферов сокращать... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2010, 14:25 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS Admin, Пришлите, пожалуйста, результат выполнения onstat -u в момент такой проболжительной обработки контрольной точки. И еще, какое у вас значение NUMCPUVPS? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2010, 16:10 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
В.К., Конечно, VPCLASS cpu,num=12,noage На сервере только IDS. 2 процессора по 4 ядра с HT. onstat -u ниже. Снял в момент выполнения КТ, до начала сброса данных из буфферов на диск. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2010, 15:23 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS Admin, Вот так я и думал... Видите букву G в первой позиции у 6 что-ли потоков... Она означает ( см. здесь, например ): Код: plaintext 1.
а буферов логического журнала в природе всего три, и сделать с этим ничего нельзя... И висеть так потоки в критических секциях кода могут и 20 минут, и больше (кому как везет, KyRo спросите ;), а поток, желающий обработать контрольную точку (в начале архивированич, в частности, но не только!), будет ждать, пока они из этого положения выйдут. Поэтому попробуйте-ка вместо num=12 сделать 3 (и не более!) виртуальных процессора класса CPU. Можете потом добавлять их динамически после архивирования и удалаять перед (если платформа позволит) с помощью onmode -p, если они вам так нужны... А лучше - так 3 и оставьте, на ваших 8 ядрах, а гипертрединг - отключите нафиг. Попробуйте, очень советую. Людям реально помогло. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2010, 20:53 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Ценная ссылочка, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2010, 23:25 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
bk0010Ценная ссылочка, спасибо В наших FAQ-ах уже много лет присутствует описание флагов 03. Что обозначают флажки в выводе onstat -u ? , так же, как и этот старый, но полезный упомянутый ресурс oninit.com Какие online-ресурсы доступны в Интернет ? - 9. Другие полезные ресурсы (англоязычные) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2010, 13:35 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Чемберлена буферов логического журнала в природе всего три, и сделать с этим ничего нельзя... Если я правильно понимаю, то можно сгладить ситуацию еще несколькими путями - включить буферирование транзакций (на нормальной кластерной системе да еще и с HDR ничего страшного в этом не вижу) - логические и физич. журналы размещать на отдельном высокоскоростном диске/массиве (у ТС, кажется, они и так отдельно, но быстродействующие ли ?) - если буферирование транзакций не включено, то можно уменьшить размер логическихх буферов до стандартных (onstat -l покажет эффективность использования буферов) - выполнять архивирование 0-го уровня в непроизводственное время, т.е. ночью, как это обычно и делается (это самое простое и эффективное админрешение на этот момент) Также, нужно исследовать и настраивать длительность КТ не только во время ontape, а и в обычной работе. Я ведь предлагал покопать в этом направлении - как минимум, взять статистику за час стандартной нагрузки, затем отключить различные AUTO и начать пошагово улучшать положение (и клинерсов значительно уменьшить и LRU-очередей увеличить и ручками установить количество AIO и т.д.) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2010, 13:57 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
vasilis, Все перечисленное помогало, в некоторой степени и на некоторое время. Но только уменьшение количества виртуальных процессоров до 3 решило проблему раз и навсегда, насколько я помню. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2010, 15:01 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
В.К.vasilis, Все перечисленное помогало, в некоторой степени и на некоторое время. Но только уменьшение количества виртуальных процессоров до 3 решило проблему раз и навсегда, насколько я помню. Так я об этом даже и не спорил, если ты заметил :) Я просто дополнил и другими вариантами, причем не совсем уверен в правильности их всех, ожидая, что кто-то захочет подискутировать/обсудить. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2010, 16:35 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
В.К., Чемберлен, Спасибо за совет. Выключил HT, уменьшил кол-во CPU VP до 3х (на обоих серверах, естественно). Результат тот же. Время выполнения КТ при работающем ontape не изменилось (. При слабой нагрузке + ontape ~ 30 сек. При сильной нагрузке + ontape - до 100 сек. При слабой нагрузке без ontape ~ 0-3 сек. При сильной нагрузке без ontape - 2-7 сек. Картина та же: интенсивная запись на диски с данными при работающем ontape идет только в самом конце КТ. Где-то 2-7 секунд. Кол-во сессий, ожидающих записи в буффер логического журнала (G в первой позиции) не изменилось. vasilis, 1) Да, физ. и лог. журналы вынесены на отдельные диски. RAID10 и свой независимый контроллер с write-back кешем. 2) Спасибо за совет. Начал притворять в жизнь. Отключил автоматику для LRU и заставил их работать: Перед самым началом КТ снял onstat -b при стандартной нагрузке: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Т.е. 330 МБ надо на диски скинуть. Причем кеш записи контроллера - 256 МБ. Установил максимальный суммарный объем грязных страниц в буферах в 140 МБ и увеличил кол-во LRU очередей: Код: plaintext 1.
Уменьшил CLEANERS c 30 до 15. Время работы КТ сократилось: При слабой нагрузке + ontape 2-8 сек. При сильной нагрузке + ontape 5-10 сек. При слабой нагрузке без ontape 0-1 сек. При сильной нагрузке без ontape - 0-2 сек. Что именно дало такой эффект - пока не определил. Буду изменять параметры один за другим и смотреть на время. Но: после изменений CLEANERS и LRU сильно упала производительность системы. Особенно при удалении большого вол-ва записей. Где-то в 2 раза ( Это большой минус. 3) Насчет перевода БД в буферезированный режим. Обязательно попробую, но позже. 4) Насчет изменения размера буфера лог. журнала. Можно чуть подробнее? Ниже вывод onstat -l. Про эффективность работы буфера лог. журнала он мне ничего не говорит) [root@onldb23 ~]# onstat -l Код: 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.
На всякий случай ниже приложил текущий onconfig (). Спасибо. Код: 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. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775. 776. 777. 778. 779. 780. 781. 782. 783. 784. 785. 786. 787. 788. 789. 790. 791. 792. 793. 794. 795. 796. 797. 798. 799. 800. 801. 802. 803. 804. 805. 806. 807. 808. 809. 810. 811. 812. 813. 814. 815. 816. 817. 818. 819. 820. 821. 822. 823. 824. 825. 826. 827. 828. 829. 830. 831. 832. 833. 834. 835. 836. 837. 838. 839. 840. 841. 842. 843. 844. 845. 846. 847. 848. 849. 850. 851. 852. 853. 854. 855. 856. 857. 858. 859. 860. 861. 862. 863. 864. 865. 866. 867. 868. 869. 870. 871. 872. 873. 874. 875. 876. 877. 878. 879. 880. 881. 882. 883. 884. 885. 886. 887. 888. 889. 890. 891. 892. 893. 894. 895. 896. 897. 898. 899. 900. 901. 902. 903. 904. 905. 906. 907. 908. 909. 910. 911. 912. 913. 914. 915. 916. 917. 918. 919. 920. 921. 922. 923. 924. 925. 926. 927. 928. 929. 930. 931. 932. 933. 934. 935. 936. 937. 938. 939. 940. 941. 942. 943. 944. 945. 946. 947. 948. 949. 950. 951. 952. 953. 954. 955. 956. 957. 958. 959. 960. 961. 962. 963. 964. 965. 966. 967. 968. 969. 970. 971. 972. 973. 974. 975. 976. 977. 978. 979. 980. 981. 982. 983. 984. 985. 986. 987. 988. 989. 990. 991. 992. 993. 994. 995. 996. 997. 998. 999. 1000. 1001. 1002. 1003. 1004. 1005. 1006. 1007. 1008. 1009. 1010. 1011. 1012. 1013. 1014. 1015. 1016. 1017. 1018. 1019. 1020. 1021. 1022. 1023. 1024. 1025. 1026. 1027. 1028. 1029. 1030. 1031. 1032. 1033. 1034. 1035. 1036. 1037. 1038. 1039. 1040. 1041. 1042. 1043. 1044. 1045. 1046. 1047. 1048. 1049. 1050. 1051. 1052. 1053. 1054. 1055. 1056. 1057. 1058. 1059. 1060. 1061. 1062. 1063. 1064. 1065. 1066. 1067. 1068. 1069. 1070. 1071. 1072. 1073. 1074. 1075. 1076. 1077. 1078. 1079. 1080. 1081. 1082. 1083. 1084. 1085. 1086. 1087. 1088. 1089. 1090. 1091. 1092. 1093. 1094. 1095. 1096. 1097. 1098. 1099. 1100. 1101. 1102. 1103. 1104. 1105. 1106. 1107. 1108. 1109. 1110. 1111. 1112. 1113. 1114. 1115. 1116. 1117. 1118. 1119. 1120. 1121. 1122. 1123. 1124. 1125. 1126. 1127. 1128. 1129. 1130. 1131. 1132. 1133. 1134. 1135. 1136. 1137. 1138. 1139. 1140. 1141. 1142. 1143. 1144. 1145. 1146. 1147. 1148. 1149. 1150. 1151. 1152. 1153. 1154. 1155.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 14:06 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS Admin, с вами интересно работать, сами читаете, разбираетесь, пробуете, задаете внятные вопросы и также сами отвечаете. Чтобы и дальше было продуктивно представьте некоторую информацию, которую я ранее просил vasilis...как минимум, взять статистику за час стандартной нагрузки... т.е. сбросить статистику onstat -z, а затем после часа обычной работы сервера (без всяких бэкапов, загрузок, импортов и т.п.) сохранить выводы команд в файл. И приложите здесь в rar или zip Интересует прежде всего onstat -a. Чтобы не считать вручную было бы неплохо выполнить ряд sql-запросов из DBA_Tools (если он у вас есть), а именно запросы с префиксом profile_ Правда, на 11.5 запросы не проверялись, поэтому могут быть ошибки... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 16:53 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Коллеги, мне кажется, что пытаясь уменьшить длительность КТ, мы упускаем следующий нюанс: логика работы прикладного ПО, данная нам (как админам) в виде ощущения длительно выполняющихся транзакций :). Если приложение выполняет в пределах одной транзакции массивные операции, либо после начала транзакции и до её завершения существует ощутимая задержка (по вине/логике клиента), то начатая КТ ждёт завершения такой транзакции, правильно? Или нынче шибко умный IDS её даже не начинает, поджидая момент (AUTO_CKPTS 1)? :) To IDS Admin: посмотри результаты (и нам покажи для общего развития) Код: plaintext 1. 2. 3.
Вот только в syscheckpoint последние 20 чекпоинтов от текущего момента, поэтому попробуй выполнить запрос несколько раз с таким перерывом, чтобы попали все чекпоинты за интервал съёма статистики. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 17:16 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
Я не удивлюсь, если окажется, что к длинному чекпоинту приводит как раз ontape и опять проявился старый баг "OLD PAGES BACKUP", ибо я не верю в то, что он до конца побежден. 2006-й год ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 17:49 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
IDS Admin vasilis, 1) Да, физ. и лог. журналы вынесены на отдельные диски. RAID10 и свой независимый контроллер с write-back кешем. Проверьте, на самом ли деле работает write-back. Совсем не давно тут рассматривалась проблема падения производительности из-за автоматического отключения кеширования на запись. IDS Admin 2) Спасибо за совет. Начал притворять в жизнь. Отключил автоматику для LRU и заставил их работать: Перед самым началом КТ снял onstat -b при стандартной нагрузке: ... Т.е. 330 МБ надо на диски скинуть. Причем кеш записи контроллера - 256 МБ. Причем эти 330МБ еще надо найти (все модифицированные страницы) по LRU-очередям, на которых тоже есть очередь и блокировки, затем отсортировать по чанкам и затем записать такой объем на диски. Так что вы правильно поняли идею и пошли правильным путем - надо уменьшить суммарный объем записываемый на диски во время КТ. IDS Admin Установил максимальный суммарный объем грязных страниц в буферах в 140 МБ и увеличил кол-во LRU очередей: BUFFERPOOL size=2K,buffers=4000000,lrus=256,lru_min_dirty=0.100000,lru_max_dirty=0.300000 BUFFERPOOL size=8K,buffers=1500000,lrus=256,lru_min_dirty=0.500000,lru_max_dirty=1.000000 Я бы установил еще большее количество очередей (мне кажется в 11.5 можно больше 256 ?) для таких огромных пулов, а также попробовал бы не так сильно уменьшать "окно" сброса, т.е. установил бы для начала на уровне 5 и 2% или даже 10 и 5. IDS AdminУменьшил CLEANERS c 30 до 15. Я давал рекомендацию на уменьшение исходя из представленного кусочка статистики, в котором было видно, что работало только 4-5 клинерсов. Нужно смотреть статистику сейчас, возможно 15 на таком интенсивном и постоянном сбросе уже и не будет хватать, хотя , все равно остаюсь при своем мнении, что при большом числе клинерсов узким местом уже становится контроллер диска (или сам дисковый массив) и слишком большие затраты на синхронизацию их работы. IDS Admin Время работы КТ сократилось: При слабой нагрузке + ontape 2-8 сек. При сильной нагрузке + ontape 5-10 сек. При слабой нагрузке без ontape 0-1 сек. При сильной нагрузке без ontape - 0-2 сек. Что именно дало такой эффект - пока не определил. Буду изменять параметры один за другим и смотреть на время. Результат отличный. А эффект дало то, что теперь во время КТ в наличии значительно меньше грязных страниц и работы значительно меньше. IDS Admin Но: после изменений CLEANERS и LRU сильно упала производительность системы. Особенно при удалении большого вол-ва записей. Где-то в 2 раза ( Это большой минус. "производительность системы в целом" понятие очень растяжимое :) В чем вы его мерили ? да одно сокращение КТ уже дает вам прирост общей производительности системы. А если произошло падение скорости отдельных операций, то нужно смотреть и мерить по ним - возможно, этих операций и немного, относительно всей системы... IDS Admin 4) Насчет изменения размера буфера лог. журнала. Можно чуть подробнее? Ниже вывод onstat -l. Про эффективность работы буфера лог. журнала он мне ничего не говорит) Logical Logging Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io L-2 3 32 7631596 981379 611378 7.8 1.6 Буфер сбрасывается в журнал целиком, а в среднем там меньше двух страниц, при размере буфера в 16 2К-страниц. Т.е. буфера переключаются слишком быстро и не успевают сбрасываться на диск (это если рассматривать ситуацию, описанную В.К.). Если будет буферизация, то буфер будет сбрасываться только после заполнения, (т.е. преключения будут более редки) т.о. давая время на сброс двум другим буферам. IDS Admin На всякий случай ниже приложил текущий onconfig (). Немного покомментирую и позадаю вопросы.... PHYSFILE 16500000 Зачем такой огромный ? Ведь обслуживать такой файл и искать там нужную точку тоже нужно время. В моей жизни 1-2Гб хватало даже в самых нагруженных системах, но на истину не претендую. AUTO_AIOVPS 1 Тоже отключил бы и, помониторив, установил бы ручками. Я не знаю логики работы этого автомата, но обычно они все заточены под некие очень стандартные и условные параметры. Знающий человек почти всегда сделает лучше. RESIDENT 0 рекомендую 1 или 2. CKPTINTVL 150 А зачем уменьшали диапазон ? Это меньше 3-х минут. Установите стандартные 300, а я бы даже и увеличил до 600. AUTO_CKPTS 1 тоже самое, что я уже писал по поводу "автоматов" TAPEDEV /dev/null LTAPEDEV /dev/null А это как понять ? У вас разве не промсистема ? Надеюсь, что это тестовая. Куда пишутся архивы - на диск или ленту? если на диски, то блок можно увеличивать - в нашем ФАК-е помнится были исследования на эту тему... BTSCANNER num=1,threshold=5000,rangesize=-1,alice=6,compression=default Раньше было много проблем и ручной настройки. Сейчас ничего не могу сказать, но для тяжело нагруженной системы возможно требуется увеличение производительности битисканера. DS_NONPDQ_QUERY_MEM 128 Однозначно увеличить, хотя бы до 5М - это позволит увеличить память для сортировок OPTCOMPIND 2 здесь тоже можно будет поэкспериментировать. Поищите и на форуме и в ФАК-е на эту тему. Иногда в OLTP изменение этого параметра может хорошо ускорить некоторые запросы (но и замедлить другие :) Надо исследовать, каких у вас больше. SQLTRACE level=low,ntraces=1000,size=2,mode=user На промсистеме выключать BUFFERPOOL size=2K,buffers=4000000,lrus=256,lru_min_dirty=0.100000,lru_max_dirty=0.300000 BUFFERPOOL size=8K,buffers=1500000,lrus=256,lru_min_dirty=0.500000,lru_max_dirty=1.000000 Такие огромные пулы требуюти больших расходов на свое обслуживание. Надо тщательно помониторить процент кэширования и поиграться с размерами - вполне возможно, что ваша активная часть БД поместится и в значительно меньшем объеме. Тогда будет однозначный плюс для КТ. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 17:58 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
АнатоЛой Если приложение выполняет в пределах одной транзакции массивные операции,.... то начатая КТ ждёт завершения такой транзакции, правильно? Раньше КТ ожидала только завершения "критической части кода" в транзакции, а не завершения самой транзакции. "Критическая часть" обычно связана с операциями записи, т.е. если транзакция интенсивно пишет/апдейтит, то , обычно, КТ сильно затягивалась, просто ожидая и приостановив другие нормальные транзакции. Но, вроде, сейчас же "неблокирующие транзакции" ? Или это миф ? :) АнатоЛой Если приложение выполняет в пределах одной транзакции ...либо после начала транзакции и до её завершения существует ощутимая задержка (по вине/логике клиента), то начатая КТ ждёт завершения такой транзакции, правильно? Вроде нет. И никогда так не было. КТ выполняется "посреди" транзакций, просто приостанавливая их работу. АнатоЛой Или нынче шибко умный IDS её даже не начинает, поджидая момент (AUTO_CKPTS 1)? :) Очень сомневаюсь, но...не знаю этого автомата совсем. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 18:14 |
|
Подает HDR. Не могу понять причину.
|
|||
---|---|---|---|
#18+
DaugavaЯ не удивлюсь, если окажется, что к длинному чекпоинту приводит как раз ontape и опять проявился старый баг "OLD PAGES BACKUP", ибо я не верю в то, что он до конца побежден. 2006-й год Да, "возвращение блудного сына" было и не один раз. Так что все возможно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2010, 18:15 |
|
|
start [/forum/topic.php?fid=44&msg=36399176&tid=1607639]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 183ms |
0 / 0 |