Checkpointing


Advanced search

Message boards : Number crunching : Checkpointing

Sort
Author Message
Profile David Ball
Forum moderator
Volunteer tester
Avatar

Joined: Sep 18 06
Posts: 274
ID: 115
Credit: 1,634,401
RAC: 0
Message 4097 - Posted 24 Jun 2008 18:14:27 UTC
Last modified: 24 Jun 2008 18:16:13 UTC

I wanted to give the checkpointing behavior a good test so after 20 minutes of runtime with both cores running charmm, I stopped the boinc client completely and restarted it. I have my system set to keep suspended WUs in memory so that's the only way to get it to actually start from a checkpoint.

I won't know till it finishes the 2 WU whether they validate or not, but I did see one thing strange after re-starting the boinc client. The WUs were restarted and the progress (percent complete) picked up where it left off. One was about 11% and the other was about 14%. The strange thing was that the accumulated CPU time went back to zero and started over. On other projects, both the accumulated cpu time and the percent complete are recovered from the checkpoint.

Hope this helps.

EDIT: Machine is Vista home premium, PD 925 (3 GHz) cpu, 3.2 GB of ram, boinc client 5.10.45.
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

Profile David Ball
Forum moderator
Volunteer tester
Avatar

Joined: Sep 18 06
Posts: 274
ID: 115
Credit: 1,634,401
RAC: 0
Message 4098 - Posted 24 Jun 2008 20:42:42 UTC

One of the WU mentioned above has finished. It matched a result from a p4 on XP and got credit.

http://docking.cis.udel.edu/result.php?resultid=9978

Maybe you can tell if it really continued from the checkpoint or started over. Either way, something is wrong because when I restarted the BOINC client and the result restarted, accumulated CPU time went to zero but the percentage complete continued from approximately where it had been before I shut down the BOINC client to test it.

<core_client_version>5.10.45</core_client_version>
<![CDATA[
<stderr_txt>
Calling BOINC init.
Starting charmm run...
Calling BOINC init.
Starting charmm run...
SUCCESS - Charmm exited with code 0.
Resolving file charmm.out...
Calling BOINC finish.

</stderr_txt>
]]>
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

Profile suguruhirahara
Forum moderator
Volunteer tester
Avatar

Joined: Sep 13 06
Posts: 282
ID: 15
Credit: 56,614
RAC: 0
Message 4099 - Posted 24 Jun 2008 22:05:36 UTC
Last modified: 24 Jun 2008 22:58:33 UTC

One task is running on my host, but it seems that checkpointing isn't done;
The option checkpoint_debug works for other projects, but not for this project.

The version of boinc is 5.10.28.
http://docking.cis.udel.edu/result.php?resultid=9728

thanks,
suguruhirahara
____________

I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.

mewbysea

Joined: Apr 14 07
Posts: 6
ID: 369
Credit: 3,078,191
RAC: 0
Message 4100 - Posted 24 Jun 2008 23:09:32 UTC

I had several that ran smoothly start to finish, but no indication they ever had to pause and get out of the way for another project. Sorry, I never got a chance to "catch them in the act" and force a pause.
____________

BobCat13
Volunteer tester

Joined: Nov 14 06
Posts: 22
ID: 239
Credit: 285,322
RAC: 0
Message 4101 - Posted 24 Jun 2008 23:46:18 UTC - in response to Message ID 4098 .
Last modified: 24 Jun 2008 23:48:08 UTC

One of the WU mentioned above has finished. It matched a result from a p4 on XP and got credit.

http://docking.cis.udel.edu/result.php?resultid=9978

Maybe you can tell if it really continued from the checkpoint or started over. Either way, something is wrong because when I restarted the BOINC client and the result restarted, accumulated CPU time went to zero but the percentage complete continued from approximately where it had been before I shut down the BOINC client to test it.

A true checkpoint is not being stored. Instead, it is a file named percentdone.txt which holds some restart data. The percentdone.txt doesn't have the cpu time stored in it, so it will revert to 0 if the WU has to restart after a reboot or stopping of the core client. Here is the contents from one of the files:


* PERCENT DONE STREAM FILE
*
SET FDONE = 15.2312
SET RUNNAME = 1ABE
SET SEED = 1.699129E+06
SET RANDSEED = 1.651957E+06
SET MAXIC = 320
SET MAXROT = 20
SET NUMIC = 46
SET RNUM = 20
SET MAXENER = -8.42386
SET MAXRMSD = 0.168544
SET REJECTS = 0
SET STEPSDONE = 920


Somewhere in there the current cpu time needs to be recorded.
Profile Michela
Forum moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar

Joined: Sep 13 06
Posts: 163
ID: 10
Credit: 97,083
RAC: 0
Message 4102 - Posted 25 Jun 2008 1:33:35 UTC - in response to Message ID 4101 .

Hi,

the script for the docking seems to miss boinc_checkpoint_completed and therefore you do not see our checkpointing. We will add it tomorrow.

Regarding the CPU that starts at 0: there must be some issues with the timing. We will look at this as well tomorrow.

We checkpoint the coordinates at the end of each conformation (random structure of the ligand). Each conformation is randomly rotated a certain number of times and each time it is docked in the protein. We will provide a table of the times for different machine between two checkpoints soon.

The percentdone.txt file keeps track of the point when the last checkpoint was done. The fraction done is the variable FDONE.

Thanks for all your help and patience!

Michela


____________
If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'!

Profile Andre Kerstens
Forum moderator
Project tester
Volunteer tester
Avatar

Joined: Sep 11 06
Posts: 749
ID: 1
Credit: 15,199
RAC: 0
Message 4103 - Posted 25 Jun 2008 1:55:12 UTC - in response to Message ID 4098 .
Last modified: 25 Jun 2008 1:56:52 UTC

Hi David,

I think I've seen this behavior before when the project was still at utep. The percentage done is provided to boinc by the application (in this case the value of FDONE from the percentdone.txt file that Michela mentions below), but boinc itself is supposed to update the cpu time value. It's possible that the new boinc version does this different than the previous version we used at utep. Arun, you might want to check that out.

Cheers
Andre

PS The current checkpoint seems to work fine, it's just not visible yet, but Arun will correct that tomorrow if I understand it correctly.

One of the WU mentioned above has finished. It matched a result from a p4 on XP and got credit.

http://docking.cis.udel.edu/result.php?resultid=9978

Maybe you can tell if it really continued from the checkpoint or started over. Either way, something is wrong because when I restarted the BOINC client and the result restarted, accumulated CPU time went to zero but the percentage complete continued from approximately where it had been before I shut down the BOINC client to test it.

<core_client_version>5.10.45</core_client_version>
<![CDATA[
<stderr_txt>
Calling BOINC init.
Starting charmm run...
Calling BOINC init.
Starting charmm run...
SUCCESS - Charmm exited with code 0.
Resolving file charmm.out...
Calling BOINC finish.

</stderr_txt>
]]>

____________
D@H the greatest project in the world... a while from now!
Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4106 - Posted 25 Jun 2008 18:38:03 UTC - in response to Message ID 4102 .

Hi,

the script for the docking seems to miss boinc_checkpoint_completed and therefore you do not see our checkpointing. We will add it tomorrow.

Regarding the CPU that starts at 0: there must be some issues with the timing. We will look at this as well tomorrow.

We checkpoint the coordinates at the end of each conformation (random structure of the ligand). Each conformation is randomly rotated a certain number of times and each time it is docked in the protein. We will provide a table of the times for different machine between two checkpoints soon.

The percentdone.txt file keeps track of the point when the last checkpoint was done. The fraction done is the variable FDONE.

Thanks for all your help and patience!

Michela



Thanks Dr. Taufer. We have added boinc_checkpoint_completed to the charmm script and now the CPU time should start from the previous time before the task was suspended/stopped. Now in the stderr.txt file you should see the message: "Starting charmm run (initial or from checkpoint)". We will distribute 300 WUs to test this.

Thanks for your feedback and help !

Arun
Rene
Volunteer tester
Avatar

Joined: Oct 2 06
Posts: 121
ID: 160
Credit: 109,415
RAC: 0
Message 4107 - Posted 25 Jun 2008 19:47:56 UTC

25-6-2008 21:32:30|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:32:35|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:33:09|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:33:36|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:33:49|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:34:29|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:34:36|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:35:11|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:35:37|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:35:52|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:36:31|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:36:37|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:37:11|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:37:37|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:37:51|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:38:32|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:38:38|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:39:11|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed
25-6-2008 21:39:38|SETI@home Beta Test|[checkpoint_debug] result ap_23ap08aa_B0_P1_00126_20080619_14751.wu_1 checkpointed
25-6-2008 21:39:52|Docking@Home|[checkpoint_debug] result 1tng_mod0011sc_621_255286_1 checkpointed


Looks OK from here, did a stop and go with the BOINC manager and the wu picked up it's previous checkpoint and running time.

;-)

____________
BobCat13
Volunteer tester

Joined: Nov 14 06
Posts: 22
ID: 239
Credit: 285,322
RAC: 0
Message 4108 - Posted 25 Jun 2008 19:50:13 UTC - in response to Message ID 4106 .

Thanks Dr. Taufer. We have added boinc_checkpoint_completed to the charmm script and now the CPU time should start from the previous time before the task was suspended/stopped. Now in the stderr.txt file you should see the message: "Starting charmm run (initial or from checkpoint)". We will distribute 300 WUs to test this.

Thanks for your feedback and help !

Arun

Checkpointing is working here. Upon stopping the daemon, the current time of last checkpoint is written into the init_data.xml and the client reverts to that time when resuming the task. I notice it does checkpoint quite often, about every 22 seconds on this machine even though I have the preferences set to 300 seconds. Not a problem, but it does make for a lot of messages with checkpoint debugging enabled.
Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4112 - Posted 25 Jun 2008 22:21:28 UTC - in response to Message ID 4108 .


Checkpointing is working here. Upon stopping the daemon, the current time of last checkpoint is written into the init_data.xml and the client reverts to that time when resuming the task. I notice it does checkpoint quite often, about every 22 seconds on this machine even though I have the preferences set to 300 seconds. Not a problem, but it does make for a lot of messages with checkpoint debugging enabled.


Thanks for letting us know checkpointing is working fine. The model we are running right now is a simple model. And since we are checkpointing at the end of each confirmation, the time between each checkpointing is low. We are developing newer models which will have higher time interval (~6 minutes) between each checkpointing.

For the current model the time is around 70-80 seconds on a old P4 machines and 16-20 seconds on a dual core machines for 1abe and 1tng complexes.

Thanks for your feedback and help !

Arun
sentient_life
Volunteer tester

Joined: Nov 14 06
Posts: 3
ID: 245
Credit: 145,797
RAC: 0
Message 4114 - Posted 25 Jun 2008 23:12:34 UTC

I realize at this point that you are concentrating on solving checkpointing issues. However, I've noticed two validated test workunits of mine have problems in relation to credits claimed vs. granted. Right now, it seems that the lowest credit claimed results in both computers granted that credit, regardless of when they were returned. On the following two workunits, my wingman's results brought the granted value down quite sharply. The crunched times are very different, also:

http://docking.cis.udel.edu/workunit.php?wuid=3481
http://docking.cis.udel.edu/workunit.php?wuid=3382

This is a similar occurrence with another project: cpu_time bug

Profile Michela
Forum moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar

Joined: Sep 13 06
Posts: 163
ID: 10
Credit: 97,083
RAC: 0
Message 4115 - Posted 25 Jun 2008 23:34:33 UTC - in response to Message ID 4114 .

Hi,

Thanks for the link. As soon as we fix the problem with the linux executable that is taking more time than the Windows, we will move to fix credits per work-unit and this should address this issue. Arun is working on this.

We will keep you posted,

Michela
____________
If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'!

sentient_life
Volunteer tester

Joined: Nov 14 06
Posts: 3
ID: 245
Credit: 145,797
RAC: 0
Message 4117 - Posted 26 Jun 2008 0:51:33 UTC

Ah, yes. Fixed credits would certainly solve it.

Profile David Ball
Forum moderator
Volunteer tester
Avatar

Joined: Sep 18 06
Posts: 274
ID: 115
Credit: 1,634,401
RAC: 0
Message 4121 - Posted 26 Jun 2008 16:22:15 UTC

I ran the same test as before (stopped and re-started the BOINC client) and everything worked great this time. The cpu time and WU progress continued from the last checkpoint and the WUs validated. Looks good.
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

mewbysea

Joined: Apr 14 07
Posts: 6
ID: 369
Credit: 3,078,191
RAC: 0
Message 4139 - Posted 28 Jun 2008 12:11:39 UTC

I had at least two wu's in the last batch that successfully paused to allow other projects in BOINC to crunch and then resumed to finish. Both had an initial estimated work time of about 7hrs20min, and actually completed in about 2 hours. Pause was at about 1hr40min.

See wu 3394 and wu 4034 for details.
____________

Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4140 - Posted 30 Jun 2008 19:06:05 UTC - in response to Message ID 4139 .

I had at least two wu's in the last batch that successfully paused to allow other projects in BOINC to crunch and then resumed to finish. Both had an initial estimated work time of about 7hrs20min, and actually completed in about 2 hours. Pause was at about 1hr40min.

See wu 3394 and wu 4034 for details.


We have distributed 300 WUs with revised FLOPS estimate. Please give your feedback for these workunits.

Thanks
Arun
STE\/E [BlackOpsTeam]
Volunteer tester

Joined: Nov 14 06
Posts: 47
ID: 292
Credit: 10,082,802
RAC: 0
Message 4141 - Posted 30 Jun 2008 20:04:28 UTC - in response to Message ID 4140 .
Last modified: 30 Jun 2008 20:05:56 UTC

I had at least two wu's in the last batch that successfully paused to allow other projects in BOINC to crunch and then resumed to finish. Both had an initial estimated work time of about 7hrs20min, and actually completed in about 2 hours. Pause was at about 1hr40min.

See wu 3394 and wu 4034 for details.


We have distributed 300 WUs with revised FLOPS estimate. Please give your feedback for these workunits.

Thanks
Arun


What are we supposed to be looking for with the revised FLOPS estimate, the time it takes to run the Wu compared to the Time it estimates it will run it ... ???
Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4142 - Posted 30 Jun 2008 20:14:28 UTC - in response to Message ID 4141 .



What are we supposed to be looking for with the revised FLOPS estimate, the time it takes to run the Wu compared to the Time it estimates it will run it ... ???


Yes, also if the number of tasks your client is getting based on the new FLOPS count for each complex is appropriate for your client setting and host cpu speed.
Related discussion .

Thanks for your feedback.

Arun
STE\/E [BlackOpsTeam]
Volunteer tester

Joined: Nov 14 06
Posts: 47
ID: 292
Credit: 10,082,802
RAC: 0
Message 4143 - Posted 30 Jun 2008 20:18:31 UTC
Last modified: 30 Jun 2008 20:54:11 UTC

Okay, I recieved quite a few of the Wu's (about 220, musta been putting in calls just at the right time) across my Parm but will run them as fast as can ... :) ... I should have them run out by the morning.

PS: Finished 2 Wu's on 1 Box in 1:30:12 that were estimated to run 1:59;34 ...

Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4144 - Posted 30 Jun 2008 21:01:28 UTC - in response to Message ID 4143 .

Okay, I recieved quite a few of the Wu's (about 220, musta been putting in calls just at the right time) across my Parm but will run them as fast as can ... :) ... I should have them run out by the morning.

PS: Finished 2 Wu's on 1 Box in 1:30:12 that were estimated to run 1:59;34 ...


You sure did get a lot of the WUs ! Looks like the FLOPS estimate is more closer to the actual running time. With checkpointing it may take different time on other hosts with similar resources.

Thanks for your feedback.

Arun
STE\/E [BlackOpsTeam]
Volunteer tester

Joined: Nov 14 06
Posts: 47
ID: 292
Credit: 10,082,802
RAC: 0
Message 4145 - Posted 30 Jun 2008 21:42:44 UTC
Last modified: 30 Jun 2008 21:55:52 UTC

Finished 2 more on another Widows Box in 1:49:16 that were Estimated to run between 2:07:55 & 2:20:42 so the Estimates seem a little high but personally I would rather have them on the high side a little so you don't overload with them when you first start to get some ... :)

The BOINC Manager will bring the Time down accordingly so you get the proper amount after running some of them.

2 also Finished on a Linux Box, the Estimates seem to be further off on that one, finished in 1:15:00 with and estimate of about 2:15:00 ...

The Check Pointing seems to work fine too, I shut down BOINC on 1 Box & when I started it back up the Times where very close to where they were when shut down.

As far as getting a lot of the Wu's goes it's because I have my Connect settings at 1 day & like I said the Pharm musta been calling just @ the right Time, I set it at that mainly because of the other projects I run have a tendency to have the Servers go down so I try to keep a supply of work on hand at all times.

Having a day of work from a Project or 2 is no problem for me to finish them on time because all my Box's are Overclocked Quads so they run the work out fairly fast IMO ... :)

STE\/E [BlackOpsTeam]
Volunteer tester

Joined: Nov 14 06
Posts: 47
ID: 292
Credit: 10,082,802
RAC: 0
Message 4146 - Posted 1 Jul 2008 17:04:52 UTC

Have all but 8 of the 220 turned in already, those 8 are on my slowest Quad but will be done soon too ... :)

mewbysea

Joined: Apr 14 07
Posts: 6
ID: 369
Credit: 3,078,191
RAC: 0
Message 4147 - Posted 1 Jul 2008 23:25:17 UTC

Running much closer to the estimates this time, and pausing and resuming as expected.

This 1abe wu estimated at about 1hr52min, completed in about 1hr45min.

This 1tng wu estimated at about 2hr3min and hit almost on the nose.

Running Q6600 2.4 GHz with Vista for both.
____________

Message boards : Number crunching : Checkpointing

Database Error
: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) {
  [0]=>
  array(7) {
    ["file"]=>
    string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc"
    ["line"]=>
    int(97)
    ["function"]=>
    string(8) "do_query"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#29 (2) {
      ["db_conn"]=>
      resource(108) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(51) "update DBNAME.thread set views=views+1 where id=313"
    }
  }
  [1]=>
  array(7) {
    ["file"]=>
    string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc"
    ["line"]=>
    int(60)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#29 (2) {
      ["db_conn"]=>
      resource(108) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(3) "313"
        ["forum"]=>
        string(1) "2"
        ["owner"]=>
        string(3) "115"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(13) "Checkpointing"
        ["timestamp"]=>
        string(10) "1214954717"
        ["views"]=>
        string(3) "731"
        ["replies"]=>
        string(2) "23"
        ["activity"]=>
        string(20) "3.6424167844076e-102"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1214331267"
        ["hidden"]=>
        string(1) "0"
        ["sticky"]=>
        string(1) "0"
        ["locked"]=>
        string(1) "0"
      }
      [1]=>
      &string(6) "thread"
      [2]=>
      &string(13) "views=views+1"
    }
  }
  [2]=>
  array(7) {
    ["file"]=>
    string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php"
    ["line"]=>
    int(184)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(11) "BoincThread"
    ["object"]=>
    object(BoincThread)#3 (16) {
      ["id"]=>
      string(3) "313"
      ["forum"]=>
      string(1) "2"
      ["owner"]=>
      string(3) "115"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(13) "Checkpointing"
      ["timestamp"]=>
      string(10) "1214954717"
      ["views"]=>
      string(3) "731"
      ["replies"]=>
      string(2) "23"
      ["activity"]=>
      string(20) "3.6424167844076e-102"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1214331267"
      ["hidden"]=>
      string(1) "0"
      ["sticky"]=>
      string(1) "0"
      ["locked"]=>
      string(1) "0"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(13) "views=views+1"
    }
  }
}
query: update docking.thread set views=views+1 where id=313