Jmeter is taking always the same time to finish remote test. The jmx script is simple and there is no time configured on it, and there are just one request (only 84ms in local test).
It happens only on remote test, in local test is ok.
Starting the test on host x.x.x.x # Thu Aug 14 09:31:43 BRT 2014 (1408019503091)
Finished the test on host x.x.x.x # Thu Aug 14 09:34:43 BRT 2014 (1408019683082)
Starting the test on host x.x.x.x # Thu Aug 14 09:35:53 BRT 2014 (1408019753107)
Finished the test on host x.x.x.x # Thu Aug 14 09:38:53 BRT 2014 (1408019933091)
Starting the test on host x.x.x.x # Thu Aug 14 09:40:33 BRT 2014 (1408020033110)
Finished the test on host x.x.x.x # Thu Aug 14 09:43:33 BRT 2014 (1408020213100)
Starting the test on host x.x.x.x # Thu Aug 14 10:03:23 BRT 2014 (1408021403158)
Finished the test on host x.x.x.x # Thu Aug 14 10:06:23 BRT 2014 (1408021583154)
Starting the test on host x.x.x.x # Thu Aug 14 10:07:53 BRT 2014 (1408021673181)
Finished the test on host x.x.x.x # Thu Aug 14 10:10:53 BRT 2014 (1408021853164)
Starting the test on host x.x.x.x # Thu Aug 14 10:25:23 BRT 2014 (1408022723204)
Finished the test on host x.x.x.x # Thu Aug 14 10:28:23 BRT 2014 (1408022903204)
Starting the test on host x.x.x.x # Thu Aug 14 10:33:13 BRT 2014 (1408023193224)
Finished the test on host x.x.x.x # Thu Aug 14 10:36:53 BRT 2014 (1408023413225)
Related
I'm using elasticdump and got weird error
Mon, 14 Nov 2022 14:42:21 GMT | starting dump
Mon, 14 Nov 2022 14:42:22 GMT | got 10 objects from source elasticsearch (offset: 0)
Mon, 14 Nov 2022 14:42:22 GMT | sent 10 objects to destination file, wrote 10
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Total Writes: 0
Mon, 14 Nov 2022 14:42:22 GMT | dump ended with error (get phase) => MOVED_PERMANENTLY: This and all future requests should be directed to the given URI.
It successfully moved 10 objects and stopped
--input-index is for a different use case.
Try with just --input like this
elasticdump --input=http://localhost/dev_index --output=test2.json
I use an apache storm topology on a cluster of 8+1 machines. The date on these machines is not the same and we may have more than 5 minutes of difference.
preprod-storm-nimbus-01:
Thu Feb 25 16:20:30 GMT 2016
preprod-storm-supervisor-01:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-02:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-03:
Thu Feb 25 16:14:54 UTC 2016 <<-- this machine is very late :(
preprod-storm-supervisor-04:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-05:
Thu Feb 25 16:20:17 GMT 2016
preprod-storm-supervisor-06:
Thu Feb 25 16:20:00 GMT 2016
preprod-storm-supervisor-07:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-08:
Thu Feb 25 16:19:55 GMT 2016
preprod-storm-supervisor-09:
Thu Feb 25 16:20:30 GMT 2016
Question:
Is the storm topology affected by this non-synchronization?
Note: I know that synchronizing is better, but the sysadmins won't do it without proving them proofs/reasons that they have to do it. Do they really have to do it, "for the topology's sake" :) ?
Thanks
It depends on the computation you are doing... It might have an effect on your result if you do time based window operations. Otherwise, it doesn't matter.
For Storm as an execution engine it has no effect at all.
I have a single instance of MongoDB 2.4.8 running on Windows Server 2012 R2. MongoDB is installed as a Windows Service. I have journalling enabled.
The MongoDB documentation suggests that the MongoDB service should just be shut down via the Windows Service Control Manager:
net stop MongoDB
When I did this recently, the following was logged and I ended up with a non-zero byte mongod.lock file on disk. (I used the --repair option to fix this but it turns out this probably wasn't necessary as I had journalling enabled.)
Thu Nov 21 11:08:12.011 [serviceShutdown] got SERVICE_CONTROL_STOP request from Windows Service Control Manager, will terminate after current cmd ends
Thu Nov 21 11:08:12.043 [serviceShutdown] now exiting
Thu Nov 21 11:08:12.043 dbexit:
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close listening sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1492
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1500
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to flush diaglog...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: waiting for fs preallocator...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: lock for final commit...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: final commit...
Thu Nov 21 11:08:12.043 [conn1333] end connection 127.0.0.1:51612 (18 connections now open)
Thu Nov 21 11:08:12.043 [conn1331] end connection 127.0.0.1:51610 (18 connections now open)
...snip...
Thu Nov 21 11:08:12.043 [conn1322] end connection 10.1.2.212:53303 (17 connections now open)
Thu Nov 21 11:08:12.043 [conn1337] end connection 127.0.0.1:51620 (18 connections now open)
Thu Nov 21 11:08:12.839 [serviceShutdown] shutdown: closing all files...
Thu Nov 21 11:08:14.683 [serviceShutdown] Progress: 5/163 3% (File Closing Progress)
Thu Nov 21 11:08:16.012 [serviceShutdown] Progress: 6/163 3% (File Closing Progress)
...snip...
Thu Nov 21 11:08:52.030 [serviceShutdown] Progress: 143/163 87% (File Closing Progress)
Thu Nov 21 11:08:54.092 [serviceShutdown] Progress: 153/163 93% (File Closing Progress)
Thu Nov 21 11:08:55.405 [serviceShutdown] closeAllFiles() finished
Thu Nov 21 11:08:55.405 [serviceShutdown] journalCleanup...
Thu Nov 21 11:08:55.405 [serviceShutdown] removeJournalFiles
Thu Nov 21 11:09:05.578 [DataFileSync] ERROR: Client::shutdown not called: DataFileSync
The last line is my main concern.
I'm also interested in how MongoDB is able to take longer to shut down than Windows normally allows for service shutdown? At what point is it safe to shut down the machine without checking the log file?
I have a arch 64bit VPS on digitalocean. I installed gwan and run it in deamon mode. It stopped running every midnight.
Here is the log file
[Wed Apr 24 06:10:28 2013 GMT] memory footprint: 3.78 MiB
[Thu, 25 Apr 2013 00:00:19 GMT] * child abort(8) coredump
[Thu, 25 Apr 2013 00:00:19 GMT] * child abort(8) coredump
[Thu, 25 Apr 2013 00:00:19 GMT] * child abort(8) coredump
[Thu, 25 Apr 2013 00:00:19 GMT] * child died 3 times within 3 seconds
[Thu Apr 25 12:39:39 2013 GMT] memory footprint: 3.77 MiB.
[Thu Apr 25 12:39:56 2013 GMT] loaded maintenance script/opt/gwan_linux64-bit/0.0.0.0_8080/#0.0.0.0/csp/crash.c 43.14 KiB MD5:820cf6b4-2152b838-08a13fcb-5f0dc4be
[Fri, 26 Apr 2013 00:00:10 GMT] * child abort(8) coredump
[Fri, 26 Apr 2013 00:00:10 GMT] * child abort(8) coredump
[Fri, 26 Apr 2013 00:00:10 GMT] * child abort(8) coredump
[Fri, 26 Apr 2013 00:00:10 GMT] * child died 3 times within 3 seconds
This problem does not happen on all platforms and so far all the user reports we received used hypervisors which alter the CPU and OS behavior in erratic and undocumented ways (not to cite the additional bugs they inject into the system).
UPDATE
That new problem for 4-years old code that worked fine so far is a platform issue, for which we have found a workaround, to be published with the next release in a few weeks.
Just reinstalled Mongodb on my mac (fresh install of mountain lion 10.8) and now my apps are taking ~3 mins to connect.
I put together a simple node script to test this:
var start = (new Date()).getTime();
var mongoose = require('mongoose');
var db = mongoose.connect('mongodb://localhost/passport-mongox',function(err){
var stop = (new Date()).getTime();
console.log('Took this long: ',(stop-start) / 1000 );
});
Both times were 175.273 and 175.316 seconds.
When I connect to an external, hosted mongodb it connects in less than a second,
Any idea why this would happen? Here is my mongo.log:
Fri Feb 1 12:43:25 [initandlisten] MongoDB starting : pid=2262 port=27017 dbpath=/usr/local/var/mongodb 64-bit host=w
Fri Feb 1 12:43:25 [initandlisten] db version v2.2.2, pdfile version 4.5
Fri Feb 1 12:43:25 [initandlisten] git version: d1b43b61a5308c4ad0679d34b262c5af9d664267
Fri Feb 1 12:43:25 [initandlisten] build info: Darwin bs-osx-106-x86-64-1.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 BOOST_LIB_VERSION=1_49
Fri Feb 1 12:43:25 [initandlisten] options: { bind_ip: "127.0.0.1", config: "/usr/local/etc/mongod.conf", dbpath: "/usr/local/var/mongodb", logappend: "true", logpath: "/usr/local/var/log/mongodb/mongo.log" }
Fri Feb 1 12:43:25 [initandlisten] journal dir=/usr/local/var/mongodb/journal
Fri Feb 1 12:43:25 [initandlisten] recover : no journal files present, no recovery needed
Fri Feb 1 12:43:26 [websvr] admin web console waiting for connections on port 28017
Fri Feb 1 12:43:26 [initandlisten] waiting for connections on port 27017
Fri Feb 1 12:44:05 [initandlisten] connection accepted from 127.0.0.1:52137 #1 (1 connection now open)
Fri Feb 1 12:44:40 [initandlisten] connection accepted from 127.0.0.1:52152 #2 (2 connections now open)
Fri Feb 1 12:45:15 [initandlisten] connection accepted from 127.0.0.1:52201 #3 (3 connections now open)
Fri Feb 1 12:45:50 [initandlisten] connection accepted from 127.0.0.1:52298 #4 (4 connections now open)
Fri Feb 1 12:46:25 [initandlisten] connection accepted from 127.0.0.1:52325 #5 (5 connections now open)
Fri Feb 1 12:51:26 [conn5] end connection 127.0.0.1:52325 (4 connections now open)
Fri Feb 1 12:51:26 [conn3] end connection 127.0.0.1:52201 (4 connections now open)
Fri Feb 1 12:51:26 [conn4] end connection 127.0.0.1:52298 (4 connections now open)
Fri Feb 1 12:51:26 [conn1] end connection 127.0.0.1:52137 (4 connections now open)
Fri Feb 1 12:51:26 [conn2] end connection 127.0.0.1:52152 (4 connections now open)
Answer from mongoose.js
Cause:
The underlying MongoDB driver defaults to looking for IPv6 addresses,
so the most likely cause is that your localhost DNS mapping isn't configured to handle IPv6.
Solution :
Use 127.0.0.1 instead of localhost or use the family option as shown in the connection docs.
mongoose.connect(url, {family:4}, function(err, connection) {
connection.db(your_db_name);
});
So the answer came from #AdamMeghji on twitter.
My hosts file has always looked like this:
127.0.0.1 localhost
127.0.0.1 test.com
127.0.0.1 wes.dev
I switched that to:
127.0.0.1 localhost test.com wes.dev
and connections went back to 0.015 seconds.