|
|
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Всем доброе время суток. Пробую смигрировать БД с 32 на 64 битную платформу, есть при этом бэкап БД (весит 233 Гб). С помощью следующего скрипта делаю рестор: Код: sql 1. при этом на начальном этапе скорость космическая (диск SSD), за час восстановилось порядка 75 Гб, и после этого включаются резкие тормоза, за следующий час скорость восстановления - 3 Гб!! Это катастрофа, куда смотреть, что можно подправить? Конфиг прилагаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:01 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Вот такая нагрузка на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:04 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, Выдержки из приложенного файла: Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:16 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
ursidoSheriffua, Выдержки из приложенного файла: Код: sql 1. 2. 3. 4. 5. 6. 7. И что из этого следует? Код: sql 1. 2. специально отключил взял здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:27 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
SheriffuaИ что из этого следует? Я заранее согласен с товарищем qwwq. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:48 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
ursidoSheriffuaИ что из этого следует? Я заранее согласен с товарищем qwwq.тс же пояснил, что это разовое послабление на момент загрузки. В случае фейла просто всё сносится, кластер заново инициируется и заливается по новой. а вот на живой базе -- это заход на дарвиновскую -- недавно кого-то максим колол -- обсыпались файлики напрочь при отключённом fsync. я думаю майнтейнанс_ворк_мем вам бы добавить, например. думаю, база индексированием могла заняться тут то и просела в "дисковом приращении". но я ни разу не админ. подождем спецов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:00 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
PS посмотрите Код: sql 1. чем там базёнка в это время занимается оно и прояснеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:08 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwqursidoпропущено... Я заранее согласен с товарищем qwwq.тс же пояснил, что это разовое послабление на момент загрузки. В случае фейла просто всё сносится, кластер заново инициируется и заливается по новой. а вот на живой базе -- это заход на дарвиновскую -- недавно кого-то максим колол -- обсыпались файлики напрочь при отключённом fsync. я думаю майнтейнанс_ворк_мем вам бы добавить, например. думаю, база индексированием могла заняться тут то и просела в "дисковом приращении". но я ни разу не админ. подождем спецов. Вы правы, это разовое послабление на момент рестора. Может есть еще доп.рекомендации, т.к. когда рестор того же бэкапа делался, НО на 32 битную платформу, время восстановления было 10 часов, пробовал использовать этот конфиг, чуда не произошло, теже тормоза (( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:10 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwqPS посмотрите Код: sql 1. чем там базёнка в это время занимается оно и прояснеет. Результат в файле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:16 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, Нужно понять где затык. А что выдаст такой запрос?Желательно запустить в `psql` с ключём `\x` (для построчного вывода колонок): Код: sql 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. Также надо бы bgwriter поболее выкрутить:namesettingbgwriter_delay100bgwriter_lru_maxpages1000bgwriter_lru_multiplier5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:19 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
vyegorov, Код: sql 1. 2. 3. у меня версия БД 9.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:28 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Странно. Тогда почему для разового действия не выкручены другие параметры. Например, мне кажется, что max_connections можно выставить в 20 shared_buffers можно выставить в 4 GB (1/4 от имеющейся) max_prepared_transactions выставить в 0 work_mem можно выставить в 256MB Что-нибудь подумать над checkpoint_segments / checkpoint_timeout (например выставить в 16 / 1h) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:30 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, ну вот -- там чорным по белому написано: делается в один поток Код: sql 1. осталось выяснить, что такое этот document, созданы к моменту COPY по нему уже индексы да констрайнты или нет. а если созданы -- то сколько их. в приведенной вами статье есть рекомендация вынести создание логики (констрентов) и тяжёлых индексов вынести в отдельный этап. Но тогда руками надо дамп пилить. а это лениво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:37 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffuavyegorov, Код: sql 1. 2. 3. у меня версия БД 9.3похоже вы левым гуём пользуетесь. на моей памяти какой--то левый гуй скрадывал повторный :: в кастах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:41 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwq, пока нет не индексов не констрейнтов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:43 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
vyegorov, Результат запароса здесь: -[ RECORD 1 ]-----------+--------------------------- forced_ratio | 46.4 min_between | 3.03 write_time_avg | 84.45 sync_time_avg | 1.86 mb_total | 629683.5 mb_per_ckpt | 167.62 mbps_ckpt | 0.92 mbps_bgw | 0.09 mbps_sess | 5.30 mbps_total | 6.31 pct_ckpt | 14.6 pct_bgw | 1.4 pct_sess | 84.0 bgw_halt_only_len | 1.54 bgw_halt_ratio | 66.18 new_ratio | 0.211 uptime | 03:32:15.49 checkpoints_timed | 294 checkpoints_req | 254 checkpoints | 548 checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 buffers_checkpoint | 11757214 buffers_clean | 1163867 maxwritten_clean | 7703 buffers_backend | 67678405 buffers_backend_fsync | 0 buffers_alloc | 16975930 total_buffers | 80599486 startup | 2016-03-10 12:24:58.233+02 stats_reset | 2016-03-09 12:15:07.109+02 min_since_reset | 1662 bgwriter_delay | 200 bgwriter_lru_maxpages | 100 bgwriter_lru_multiplier | 2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 16:59 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwq, похоже что ключ: Код: sql 1. не работает при команде COPY ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:11 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, Скорее неработает с некоторыми форматами дампа, н.п. тар. Какой формат дампа у вас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:17 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Lonepsycho, Дамп делался так: pg_dump.exe" --format=custom ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:20 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffuaqwwq, похоже что ключ: Код: sql 1. не работает при команде COPY Ключ -j работает на уровне таблиц. Если у вас 1 таблица = 90% базы, то рекомендую запастись попкорном, ибо поток будет только один. Чтобы распараллелить таблицы такие, надо руками шаманить. А в моём запросе вроде всё должно быть хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:41 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:45 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, Агрессивный bgwriter, checkpoint_completion_target = 0.9, wal_buffers='16MB'. Можно попробовать ещё shared_buffers уменьшить на время загрузки данных. Можно ещё так сделать: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Но у вас 1 поток всего, так что... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 18:16 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
vyegorov, Брежу, привык на Linux-е работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 18:17 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Если с потоковостью бороться не имеет смысла, то какие основные параметры влияют на время обработки данных при ресторе? Так как в одних рекомендациях нужно увеличивать shared_buffers в других уменьшить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 18:31 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
SheriffuaЕсли с потоковостью бороться не имеет смысла, то какие основные параметры влияют на время обработки данных при ресторе? Рекомендации по загрузке данных для 9.3 здесь . На время работы pg_restore установите: archive_mode = off max_wal_senders = 0 wal_level = minimal Это позволит не писать в WAL работу COPY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 19:01 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Внес правки в файл конфигурации: Код: sql 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. существенно ничего не поменялось (( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 12:01 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
при этом на начальном этапе скорость космическая (диск SSD), за час восстановилось порядка 75 Гб, и после этого включаются резкие тормоза, за следующий час скорость восстановления - 3 Гб!! Это катастрофа, куда смотреть, что можно А что за SSD ? У меня такое чувство, что мой SSD (бытовой) пишет "пакетами". Пара Гбайт быстро, потом система зависает, потом опять работает. Сейчас приходится обрабатывать по 3-5 Gb мелких файлов, проблема с SSD на лицо ((( Возможно проблема не в PostgreSQL, а в железе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 12:21 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Это виртуалка, которая крутиться на SSD. Я уже писал выше, что тот же бэкап использовался и для восстановления на 32 битную платформу (время восстановления было=10 часам). Решили смигрировать на 64 битную платформу и здесь такие тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 12:37 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, т.е. постгрес в виртуалке? я правильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 14:16 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Lonepsycho, совершенно верно, для тестов же нужно что-то юзать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 15:01 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
SheriffuaВнес правки в файл конфигурации: Код: sql 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. существенно ничего не поменялось (( Повторные запуски в чистую БД делаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 15:21 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Павел ЛузановSheriffuaВнес правки в файл конфигурации: Код: sql 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. существенно ничего не поменялось (( Повторные запуски в чистую БД делаете? да, все удаляю, создаю БД, правлю конфиг, делаю рестарт сервера, и запускаю восстановление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 16:09 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, А что говорит мониторинг дисковой активности — как меняются IOPSы логические и физические? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 16:44 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
И так, имеем следующую картину: Когфиг БД: Код: sql 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. по нему идет восстановление БД, согласно выборке: Код: sql 1. сейчас происходит: Код: sql 1. восстановилось порядка 20Гб для этой таблицы в течении 1 часа, и после этого падает резко производительнось до 1-3 Гб в час ((( Вопрос - с чем это может быть связано??! Так как любые конфигурации файла postgresql.conf приводит к одному и тому же результату. Что можно еще сделать? Можно ли провести восстановление конкретной таблицы, а потом все остальное? Буду рад любым подсказакам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 11:35 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Вот что показывает монитор ресурсов: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 11:53 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Как-то мне кажется, что нагрузка на диск 9 Mb/s - это как то ни о чем. Команда COPY, может грузить две вещи: 1) "процессор" - например заливка данных 2) "диск" - это понятно При Вашем описании проблемы, "Это виртуалка, которая крутиться на SSD...восстановления на 32 битную платформу (время восстановления было=10 часам). Решили смигрировать на 64 битную платформу и здесь такие тормоза. " Лично у меня, складывается ощущение, что PostgreSQL тут вообще не причем. Кривое железо, драйвера, руки и так далее. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:03 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
проц - строить индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:07 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev... Лично у меня, складывается ощущение, что PostgreSQL тут вообще не причем. Кривое железо, драйвера, руки и так далее. Точно такие же мысли. При нагрузках надо смотреть на поведение физических железок, а не виртуальных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:09 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevКак-то мне кажется, что нагрузка на диск 9 Mb/s - это как то ни о чем. Команда COPY, может грузить две вещи: 1) "процессор" - например заливка данных 2) "диск" - это понятно При Вашем описании проблемы, "Это виртуалка, которая крутиться на SSD...восстановления на 32 битную платформу (время восстановления было=10 часам). Решили смигрировать на 64 битную платформу и здесь такие тормоза. " Лично у меня, складывается ощущение, что PostgreSQL тут вообще не причем. Кривое железо, драйвера, руки и так далее. IMHO & AFAIK эта виртуалка была при восстановлении на 32 битную платформу, НИЧЕГО не менялось по ней, удалили 32 битную и проинсталили 64 битную - запустил повторный рестор. Если бы были кривые настрорйки или железо, то тормоза по идее сразу бы были заметны, а так проблема проявляется после 1 часа работы . и это странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:10 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
так новаые вводные - оказывается это таки не ВМ это реальная железяка, оказывается админы не правильно нас проинформировали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:18 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, там ещё затраты на 1 длинную транзакцию надо учитывать. они наверняка нелинейные от числа записей. т.е. может оказаться, что пж таки причём. попробую ткнуть пальцем в небо: -- что говорит select * from pg_locks. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:19 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwq, select count(*) from pg_locks. --поправка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:21 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwqqwwq, select count(*) from pg_locks. --поправка Результат: 5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:29 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffuaтак новаые вводные - оказывается это таки не ВМ это реальная железяка, оказывается админы не правильно нас проинформировали. У меня SSD (бытовой) ровно так себя под нагрузкой и ведет Быстро быстро пишет первые несколько Gb, потом намертво затыкается (система зависает), потом опять просыпается. Объемы конечно не Ваши, но в поведении нет ничего странного. С учетом "на 32 бит все нормально, на 64 тормоза" - первое подозрение на систему, драйвера, железо. Но лично я бы, посмотрел, что за дисковая система и как сконфигурирована. Если там что нибудь вроде "RAID-6 самое лучшее, ставьте его" ( C ) специалисты Fujutsju - то нет ничего удивительного. qwwqтам ещё затраты на 1 длинную транзакцию надо учитывать. они наверняка нелинейные от числа записей. т.е. может оказаться, что пж таки причём. Ну что-то он должен грузить? Проц, диск.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:30 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, Мы тут сейчас будем тыкать пальцами в небо. Если есть админы — попросите продоставить графики по дискам (метсо, нагрузка), по цпу, по виртуальной памяти. Не те, что винда показывает, а подробные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:36 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Система: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:36 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev <> Ну что-то он должен грузить? Проц, диск.... хвост! т.е. память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:39 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffuavyegorov, Результат запароса здесь: -[ RECORD 1 ]-----------+--------------------------- forced_ratio | 46.4 min_between | 3.03 write_time_avg | 84.45 sync_time_avg | 1.86 mb_total | 629683.5 mb_per_ckpt | 167.62 mbps_ckpt | 0.92 mbps_bgw | 0.09 mbps_sess | 5.30 mbps_total | 6.31 pct_ckpt | 14.6 pct_bgw | 1.4 pct_sess | 84.0 bgw_halt_only_len | 1.54 bgw_halt_ratio | 66.18 new_ratio | 0.211 uptime | 03:32:15.49 checkpoints_timed | 294 checkpoints_req | 254 checkpoints | 548 checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 buffers_checkpoint | 11757214 buffers_clean | 1163867 maxwritten_clean | 7703 buffers_backend | 67678405 buffers_backend_fsync | 0 buffers_alloc | 16975930 total_buffers | 80599486 startup | 2016-03-10 12:24:58.233+02 stats_reset | 2016-03-09 12:15:07.109+02 min_since_reset | 1662 bgwriter_delay | 200 bgwriter_lru_maxpages | 100 bgwriter_lru_multiplier | 2 Могу ошибаться: checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 По доке, в ms. Т.е. checkpoint_write_time = 46 277 179 ms = 46 277 sec = 771 min = > 12 hour checkpoint_sync_time = 1 018 687 = 1 018 sec = 16 min Мне одному кажется, что это ДОФИГА. Смотрим, сколько всего информации пытался записать PostgreSQL buffers_checkpoint = 11 757 214 * 8 Kb = 94 057 712 Kb = 94 Gb Т.е. скорость диска, если верить PostgreSQL = 94 057 712 / 46 277 179 = 2 Mb / sec Где Вы такой SSD купили и/или кого к настройке дискового хранилища подпускали ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:44 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
vyegorovLeonid Kudryavtsev, Мы тут сейчас будем тыкать пальцами в небо. Если есть админы — попросите продоставить графики по дискам (метсо, нагрузка), по цпу, по виртуальной памяти. Не те, что винда показывает, а подробные . Что имеется ввиду под подробными??! вот это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:45 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Как-то мне это начинает напоминать не давнее обсуждение ))): http://www.sql.ru/forum/1197046/ssd-vs-sas ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:46 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevSheriffuavyegorov, Результат запароса здесь: -[ RECORD 1 ]-----------+--------------------------- forced_ratio | 46.4 min_between | 3.03 write_time_avg | 84.45 sync_time_avg | 1.86 mb_total | 629683.5 mb_per_ckpt | 167.62 mbps_ckpt | 0.92 mbps_bgw | 0.09 mbps_sess | 5.30 mbps_total | 6.31 pct_ckpt | 14.6 pct_bgw | 1.4 pct_sess | 84.0 bgw_halt_only_len | 1.54 bgw_halt_ratio | 66.18 new_ratio | 0.211 uptime | 03:32:15.49 checkpoints_timed | 294 checkpoints_req | 254 checkpoints | 548 checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 buffers_checkpoint | 11757214 buffers_clean | 1163867 maxwritten_clean | 7703 buffers_backend | 67678405 buffers_backend_fsync | 0 buffers_alloc | 16975930 total_buffers | 80599486 startup | 2016-03-10 12:24:58.233+02 stats_reset | 2016-03-09 12:15:07.109+02 min_since_reset | 1662 bgwriter_delay | 200 bgwriter_lru_maxpages | 100 bgwriter_lru_multiplier | 2 Могу ошибаться: checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 По доке, в ms. Т.е. checkpoint_write_time = 46 277 179 ms = 46 277 sec = 771 min = > 12 hour checkpoint_sync_time = 1 018 687 = 1 018 sec = 16 min Мне одному кажется, что это ДОФИГА. Смотрим, сколько всего информации пытался записать PostgreSQL buffers_checkpoint = 11 757 214 * 8 Kb = 94 057 712 Kb = 94 Gb Т.е. скорость диска, если верить PostgreSQL = 94 057 712 / 46 277 179 = 2 Mb / sec Где Вы такой SSD купили и/или кого к настройке дискового хранилища подпускали ? Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:50 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevКак-то мне кажется, что нагрузка на диск 9 Mb/s - это как то ни о чем. Да, верно. не могу сказать за linux, но на windows есть проблема с нагрузкой на диск. Сам работаю в windows и я смог получить примерно 4-5 Mb/s .... это максимум!!! Смог решить проблему скорости чтения данных только лишь поместив все данные в кэш (pg_prewarm) А так, да... пока кэш не разогрет, то простейшие запросы select * from firms where leader_fio ~ 'сидоров' limit 10 offset 20; работали крайне медленно. Замечу сразу, что такой запрос делал именно с цель посмотреть нагрузку по чтению на диск. Сама табличка большая 3 Гб и её надо просмотреть почти всю. Увы, как на велосипеде едем :) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. а вот после разогрева Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:52 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevSheriffuavyegorov, Результат запароса здесь: -[ RECORD 1 ]-----------+--------------------------- forced_ratio | 46.4 min_between | 3.03 write_time_avg | 84.45 sync_time_avg | 1.86 mb_total | 629683.5 mb_per_ckpt | 167.62 mbps_ckpt | 0.92 mbps_bgw | 0.09 mbps_sess | 5.30 mbps_total | 6.31 pct_ckpt | 14.6 pct_bgw | 1.4 pct_sess | 84.0 bgw_halt_only_len | 1.54 bgw_halt_ratio | 66.18 new_ratio | 0.211 uptime | 03:32:15.49 checkpoints_timed | 294 checkpoints_req | 254 checkpoints | 548 checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 buffers_checkpoint | 11757214 buffers_clean | 1163867 maxwritten_clean | 7703 buffers_backend | 67678405 buffers_backend_fsync | 0 buffers_alloc | 16975930 total_buffers | 80599486 startup | 2016-03-10 12:24:58.233+02 stats_reset | 2016-03-09 12:15:07.109+02 min_since_reset | 1662 bgwriter_delay | 200 bgwriter_lru_maxpages | 100 bgwriter_lru_multiplier | 2 Могу ошибаться: checkpoint_sync_time | 1018687 checkpoint_write_time | 46277179 По доке, в ms. Т.е. checkpoint_write_time = 46 277 179 ms = 46 277 sec = 771 min = > 12 hour checkpoint_sync_time = 1 018 687 = 1 018 sec = 16 min Мне одному кажется, что это ДОФИГА. Смотрим, сколько всего информации пытался записать PostgreSQL buffers_checkpoint = 11 757 214 * 8 Kb = 94 057 712 Kb = 94 Gb Т.е. скорость диска, если верить PostgreSQL = 94 057 712 / 46 277 179 = 2 Mb / sec Где Вы такой SSD купили и/или кого к настройке дискового хранилища подпускали ? Это кумулятивные данные, смотрите также на `stats_reset`. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:52 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua...Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD? Не знаю. Я хочу сказать, что по статистике которую отслеживает PostgreSQL (если я правильно прочитал доку и правильно поделил), 12 часов ушло на работу с диском. Почему такое не очень нормальное поведение - сказать сложно. 1) Я бы вынес файлы БД на обычный жесткий диск. Теоретически, при нормально открученных параметрах памяти и загрузки в один поток, COPY должна давать более-менее ПОСЛЕДОВАТЕЛЬНЫЙ доступ к диску. Т.ч. пусть не 80 Mb/s, но честные 40 Mb/s на любом бытовом жестком диске Вы иметь должны. Сейчас наблюдается 2 Mb/s под РЕАЛЬНОЙ нагрузкой. 2) Настройка параметров checkpoint'ов, что бы их было как можно меньше. У меня сейчас на компе аналогичное поведение SSD, правда цена у него совсем другая (6 тыс. руб) и объемы у меня другие (пара гигов). IMHO & AFAIK. Могу ошибаться. Не админ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 12:59 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevSheriffua...Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD? Не знаю. Я хочу сказать, что по статистике которую отслеживает PostgreSQL (если я правильно прочитал доку и правильно поделил), 12 часов ушло на работу с диском. Почему такое не очень нормальное поведение - сказать сложно. 1) Я бы вынес файлы БД на обычный жесткий диск. Теоретически, при нормально открученных параметрах памяти и загрузки в один поток, COPY должна давать более-менее ПОСЛЕДОВАТЕЛЬНЫЙ доступ к диску. Т.ч. пусть не 80 Mb/s, но честные 40 Mb/s на любом бытовом жестком диске Вы иметь должны. Сейчас наблюдается 2 Mb/s под РЕАЛЬНОЙ нагрузкой. 2) Настройка параметров checkpoint'ов, что бы их было как можно меньше. У меня сейчас на компе аналогичное поведение SSD, правда цена у него совсем другая (6 тыс. руб) и объемы у меня другие (пара гигов). IMHO & AFAIK. Могу ошибаться. Не админ. К сожалению нет места, чтобы вынести файлы БД на другой диск ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 13:02 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufosДа, верно. не могу сказать за linux, но на windows есть проблема с нагрузкой на диск. Сам работаю в windows и я смог получить примерно 4-5 Mb/s .... это максимум!!! ... PostgreSQL, Windows 7 max, AMD FX 4.7 Gh, SSD Kingston SUV300S37A 240G Запустил select sum( length( текстовое_поле ) ) from большая_таблица В мониторе ресурсов вижу от 40 Mb/s до 50 Mb/s чтение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 13:21 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Попробую еще восстановление запустить на диск Е, там 10й рейд скази винтов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 13:31 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, Приведите пожалуйста план запроса для 1-го вызова при отсутствии таблицы в кеше и после помещения таблицы в кеш. Хотелось бы взглянуть... и еще если можно скрин монитора ресурсов... на моей системе такой же запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. и после разогрева Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 13:45 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Запустил рестор, сейчас такая нагрузка: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 13:50 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Sheriffua, Я бы делал так: - включил бы мониторинг (так, чтобы снимки снимались часто и была бы история) на диски, CPU, память, файл подкачки - сделал бы новый кластер - настроил бы PG, уделив внимание: * WAL и контрольных точек * bgwriter * памяти: много maintenance, мало шаренных буферов * логгированию всего чего только можно: connect/disconnect, checkpoints, temp, locks * выключил бы всё, что может тормознуть (fsync, synchronous_commit) - поднял бы экземпляр и дал ему спокойно ничего делать минут 10-15, чтобы мониторинг зафикисировал базу - запустил бы восстановление - по прошествии минут 30 _после_ замедления, начал бы курить графики мониторинга и логи базы. Урывками — "вот на этом графике у меня затык!" — не увидеть, сравнить не с чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 14:19 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufosLeonid Kudryavtsev, Приведите пожалуйста план запроса для 1-го вызова при отсутствии таблицы в кеше и после помещения таблицы в кеш. Хотелось бы взглянуть... и еще если можно скрин монитора ресурсов... Не очень понимаю насчет "таблицы в кеше и после помещения таблицы в кеш." План (до и после запроса 3 строчки): "Limit (cost=355933.64..355933.65 rows=1 width=2)" " -> Aggregate (cost=355933.64..355933.65 rows=1 width=2)" " -> Seq Scan on <cencored> (cost=0.00..328573.09 rows=5472109 width=2)" Скриншоты в след. письме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 15:25 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
OFFTOPIC, по просьбе посетителей. Не очень понимаю ценность, но может действительно кому-то нужно. Выполнение запроса. Чтение с диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 15:28 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevНе очень понимаю насчет "таблицы в кеше и после помещения таблицы в кеш." Это я опечатался :) предолагалось ДО помещения таблицы в кеш. (например сразу после рестарта службы) и после помещения в кеш - select pg_prewarm('table name'); А в плане... жалко, что нет actual строчек... ожидал план полученный командой: explain (COSTS, BUFFERS, TIMING, ANALYZE, VERBOSE) SELECT .... за скриншоты спасибо. Вижу, что postgres читает со скоростью ~28 Mb/sec а какая версия самого PostgreSQL ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 16:02 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufosза скриншоты спасибо Не за что. IMHO & AFAIK особой разницы в скорости дисковой подсистемы Windows / Linux ждать не стоит. Даже наоборот. Обычно под Windows оборудование более массовое/отлажено. Т.ч. пиковые скорости скорее следует на Windows ожидать. SELECT ... - выполнялся 118 987 ms. explain ... "Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=90426.858..90426.858 rows=1 loops=1)" " Output: (sum(length(day1)))" " Buffers: shared hit=421 read=273431" " -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=90426.856..90426.857 rows=1 loops=1)" " Output: sum(length(day1))" " Buffers: shared hit=421 read=273431" " -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.011..89772.976 rows=3952248 loops=1)" " Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)" " Buffers: shared hit=421 read=273431" "Planning time: 0.084 ms" "Execution time: 90426.899 ms" выполнялся 90 sec. Explain после перезапуска службы: "Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=2782.678..2782.679 rows=1 loops=1)" " Output: (sum(length(day1)))" " Buffers: shared read=273852" " -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=2782.667..2782.668 rows=1 loops=1)" " Output: sum(length(day1))" " Buffers: shared read=273852" " -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.649..2180.144 rows=3952248 loops=1)" " Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)" " Buffers: shared read=273852" "Planning time: 0.761 ms" "Execution time: 2782.719 ms" Почему-то стало быстрее (на пару порядков) Еще одно выполнение explain plan "Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=2515.380..2515.381 rows=1 loops=1)" " Output: (sum(length(day1)))" " Buffers: shared hit=196 read=273656" " -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=2515.378..2515.378 rows=1 loops=1)" " Output: sum(length(day1))" " Buffers: shared hit=196 read=273656" " -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.006..1900.970 rows=3952248 loops=1)" " Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)" " Buffers: shared hit=196 read=273656" "Planning time: 0.058 ms" "Execution time: 2515.412 ms" С PostgreSQL explain не дружу. Т.ч. никак трактовать результаты не буду. Вообще, что-то странное. Понятно, что тесты не чистые ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 16:28 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufosа какая версия самого PostgreSQL ? Version string PostgreSQL 9.4.5, compiled by Visual C++ build 1800, 64-bit ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 16:29 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevIMHO & AFAIK особой разницы в скорости дисковой подсистемы Windows / Linux ждать не стоит. вот тут как раз и есть сомнения.... "старшие товарищи" в лице Ильи Космоденьянского - настоятельно не рекомендовали под Windows увеличивать размер буферного кеша больше 8 Гб при любом большом размере ОЗУ. - также должен отметить, что только под Linux сейчас поддерживается работа с большим объёмом ОЗУ - так называемые huge_pages - на конференциях мне говорили, что под Windows не эффективно реализован код работающий с буферным кэшом. К сожалению у меня недостаточно знаний, чтобы это подтвердить/опровергнуть. Именно поэтому хотелось получить отзыв о работе под Windows/Linux Что касается представленных планов, то они очень интересные... 1-й "Execution time: 90426.899 ms" " Buffers: shared hit=421 read=273431" говорит о том, что в буферном кеше уже нашлось 421 страница и прочитано 273431 страниц итого = 273852 2-й "Execution time: 2782.719 ms" " Buffers: shared read=273852" О как! мы всё прочитали с диска, но при этом работали 40 раз быстрее! 3-й "Execution time: 2515.412 ms" " Buffers: shared hit=196 read=273656" часть уже в буферном кеше - 196 страниц. Время работы уменьшилось. Ожидаемо если сравнивать со 2-м запросом, но не с 1-м. здесь действительно неясно почему 1-й запрос работал так долго. Возможно, что вклинились некие процессы которые просто сильно затормозили его работу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:04 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufos, Есть ещё кэш операционки, все 3 плана читают тот же файл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:08 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Тест понятно не корректный и комп в фоне молотил долгий расчет (к БД не обращался). Т.к. мне не очень понятно, что именно и для чего нужно grufos, то и смысла нет напрягаться измерить сферического коня. IMHO Если даже взять 90 sec это чтение с диска (что похоже на правду), то 273 431 * 8Kb / 90 sec = 24.3 Mb/s эффективных данных. С загрузкой 40-50 Mb/s в диспетчере задач согласуется достаточно хорошо. Всяко НЕ "примерно 4-5 Mb/s .... это максимум". Цифры IMHO вполне адекватные для рабочего компа с бытовым SSD диском. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:20 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
grufosвот тут как раз и есть сомнения.... IMHO & AFAIK Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.). IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки. Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:28 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, vyegorov, Спасибо за ответы и подсказки. Конечно я ещё буду исследовать этот вопрос с контролём счетчиков, чтобы убрать вот это "примерно 4-5 Mb/s" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:57 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevIMHO & AFAIK Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.). IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки. Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли ))) Главное чтобы коллеги владели кухней. Пока смотрю на рестор и ответа не нахожу с чем связана данная трабла, с виндой, железом, утечкой памяти... Не понимаю (( Куда пропадает скорость восстановления данных и что на нее влияет??! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 19:50 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
SheriffuaLeonid KudryavtsevIMHO & AFAIK Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.). IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки. Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли ))) Главное чтобы коллеги владели кухней. Пока смотрю на рестор и ответа не нахожу с чем связана данная трабла, с виндой, железом, утечкой памяти... Не понимаю (( Куда пропадает скорость восстановления данных и что на нее влияет??! 1)Включите полный лог запросов к базе во время рестора и посмотрите что там происходит тогда когда все уже медленно идет. или 2)попробуйте сделать --jobs=4 (или 8) для pg_restore. или 3)возьмите и попробуйте на другом сервере для теста. или 4)ВРЕМЕННО для теста на базе сделайте fsync=off и попробуйте загрузить -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 03:41 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, 4 уже -- см выше 3 -- ему не дают, [ибо it-нег] 2 -- у него одна табличка остаёцца для копей. т.е. остальные потоки в пролёте 1 -- см 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 08:29 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
qwwqMaxim Boguk, 4 уже -- см выше 3 -- ему не дают, [ибо it-нег] 2 -- у него одна табличка остаёцца для копей. т.е. остальные потоки в пролёте 1 -- см 2. Всё верно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 09:33 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
vyegorovSheriffua, Я бы делал так: - включил бы мониторинг (так, чтобы снимки снимались часто и была бы история) на диски, CPU, память, файл подкачки - сделал бы новый кластер - настроил бы PG, уделив внимание: * WAL и контрольных точек * bgwriter * памяти: много maintenance, мало шаренных буферов * логгированию всего чего только можно: connect/disconnect, checkpoints, temp, locks * выключил бы всё, что может тормознуть (fsync, synchronous_commit) - поднял бы экземпляр и дал ему спокойно ничего делать минут 10-15, чтобы мониторинг зафикисировал базу - запустил бы восстановление - по прошествии минут 30 _после_ замедления, начал бы курить графики мониторинга и логи базы. Урывками — "вот на этом графике у меня затык!" — не увидеть, сравнить не с чем. Вы говорили про этот мониторинг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 17:00 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Часть 2 от архива ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 17:01 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
- включил бы мониторинг (так, чтобы снимки снимались часто и была бы история) на диски, CPU, память, файл подкачки ... - по прошествии минут 30 _после_ замедления, начал бы курить графики мониторинга и логи базы. Урывками — "вот на этом графике у меня затык!" — не увидеть, сравнить не с чем. Cравнить не с чем. В целом, картина на затык не похожа: 1. С диска стабильно читает среднее 0.374 макс 9 Mb/s 2. На диск пишет в среднем 1.202 макс 28.373 Mb/s IMHO похоже на правду, кто БД и бекап держит в момент загрузки на одном и том же томе и нафига - вопрос риторический. 3. Процессор молотит. Загруженность процессора средняя 17%, тотал 64%. Не знаю сколько ядер в компьютере и в сколько потоков была загрузка, но мне кажется, это крайне прилично. Что удивляет: 1. Ошибок страниц в секунду: среднее 1,528 макс 49,563 Можно подумать, что что-то ушло в своп. 2. Ввод страниц в секунду (и обмен страниц в секунду) - среднее 119 макс 2,209 мне кажется, это дофига 3. Средняя длина очереди диска D - 0,327 Средняя длина очереди дисков _Total - 0,935 ОЧЕНЬ похоже, что есть какая-то еще дисковая активность, кроме диска D !!! Которая в приложенный мониторинг не вошла. Своп? Не спец. по администрированию Windows, но по ощущениям чайника: 1. Есть какой-то обмен с дисками помимо диска D. И на этих дисках, длина очереди диска явно больше, чем на диске D 2. Что-то свопиться, хотя памяти вроде дофига. Насколько "активен" своп, сказать не могу, мне сравнивать не с чем. Но явно он отличен от 0. 3. Кеш и память для меня выглядят странно. Больно маленький кеш при Ваших обменом с диском. Но не специалист. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2016, 11:44 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
С подкачкой могу ошибаться, т.к. "Память, обмен страниц/сек. Этот счетчик очень часто неправильно интерпретируют... Большое его значение необязательно подразумевает, что узкие места производительности возникают из-за недостатка ОЗУ." ( C ) MSDN "Память, вывод страниц/сек. Этот счетчик показывает, сколько страниц виртуальной памяти записывались в файл подкачки для освобождения страниц ОЗУ для других целей каждую секунду. Этот счетчик необходимо отслеживать, если вы подозреваете, что узкое место — это подкачка. Даже если значение счетчика Байт выделенной виртуальной памяти больше объема ОЗУ, проблем с производительностью из-за недостатка оперативной памяти не будет, если значение счетчика "Вывод страниц/сек" небольшое или равно нулю в течение большей части времени." Но удивляет, что: Средняя длина очереди диска D - 0,327 Средняя длина очереди дисков _Total - 0,935 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2016, 11:52 |
|
||
|
Скорость восстановления данных со временем заметно замедляется
|
|||
|---|---|---|---|
|
#18+
Вообщем переустановили винду, все вернулось на круги свои - восстановление проходит нормально, ну скажем приемлимо в один поток 9 часов. Неужели виновата таки винда в происходящем??! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2016, 13:57 |
|
||
|
|

start [/forum/topic.php?all=1&fid=53&tid=1997294]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
2ms |
check topic access: |
3ms |
track hit: |
200ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 508ms |

| 0 / 0 |
