On 10/29/2014 10:21 AM, Tory M Blue wrote: > > > On Wed, Oct 29, 2014 at 5:50 AM, Tory M Blue <tmb...@gmail.com > <mailto:tmb...@gmail.com>> wrote: > > So I've been watching paint dry since before midnight, it's now > 5:44am PST. I have no idea whether slon is actually doing anything > at this point. My slave node (did an add), is quite large the table > it's working on was 52GB when it completed the transfer and is now > 77GB, but has been that size for over 2 hours (on disk du) > > Just not sure if it's stuck or it's actually doing anything. I see > this in my stats table, and i have a single cpu pegged at 99-100% > that has been running for well; > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 54600 postgres 20 0 4617m 4.4g 2.0g R 99.7 1.7 399:57.68 > postmaster > > > > 16398 | clsdb | 54600 | 10 | postgres | > slon.remoteWorkerThread_1 | 10.13.200.232 | | > 54260 | > 2014-10-28 22:19:29.277022-07 | 2014-10-29 00:05:40.884649-07 | > 2014-10-29 01:17:22.102619-07 | 2014-10-29 01:17:22.10262-07 | f > | active | select "_cls".finishTableAfterCopy(143); analyze > "torque"."iimpressions"; > > I now have 5million rows backed up on the master.I'm watching to see > if anything negative happens, where I have to drop this node, just > so the master can truncate all that data and then start again. I'd > rather not do that if I come to believe this is still working and it > may finish in the next couple of hours? > > I've set maintenance_work_mem to 10GB to try to give this some room, > but no changes. This is a single process, but it's an index > creation, one would think it could use the 256GB of ram to it's > advantage. > > Anyways is there somewhere I can look in slon /postgres to see if > it's doing anything more then sticking a cpu to 100% and making me > crave sleep? > > Thanks > Tory > > > > Well definitely still doing something, just wish it was enough for my > system to notice.
Did you change maintenance workmem before the index rebuild started? Also, how many indexes are on the table just 1 (the primary key) index? If there is more than 1 you might want to drop the others before you subscribe the table and them concurrently later. > > Ran an strace and see a bunch of reads and writes, it's ongoing. But > hell if this is not a constrained task. All the hardware in the world > doesn't seem to be able to overcome the single tasking nature of this.. > > Also not sure why it's not taking more ram.. > > 54600 postgres 20 0 4617m 4.4g 2.0g R 98.6 1.7 490:42.28 postmaster > > Have not aborted, but getting close think I've got 5.2million rows in > sl_log1 and 1 million rows in sl_log2 now. BTW this is 9.3 with slony > 2.1.3 (2.2.3 is the next stage of this upgrade) > > Tory > > > > > _______________________________________________ > Slony1-general mailing list > Slony1-general@lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general > _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
