Skip to main content

VNETPERF error - Unable to connect to host

when running Vertica vnetperf utility you may face these errors below
although you have no FW between servers
and the communication is OK and no network errors are observed
Vertica DB is up and running on these Vertica hosts as well

[Connector Thread 172.16.8.11 ] Couldn't connect to 172.16.8.11 (family 2, attempt 0): Connection refused; errno=111 (Connection refused)

[Connector Thread 172.16.8.10 ] Couldn't connect to 172.16.8.10 (family 2, attempt 0): Connection refused; errno=111 (Connection refused)

[Connector Thread 172.16.8.12 ] Couldn't connect to 172.16.8.12 (family 2, attempt 0): Connection refused; errno=111 (Connection refused)

[Connector Thread 172.16.8.11 ] Could not find anything to connect to for 172.16.8.11; errno=111 (Connection refused)

[Connector Thread 172.16.8.10 ] Could not find anything to connect to for 172.16.8.10; errno=111 (Connection refused)

[Connector Thread 172.16.8.12 ] Could not find anything to connect to for 172.16.8.12; errno=111 (Connection refused)

Unable to connect to host 172.16.8.10:14159
Unable to connect to host 172.16.8.11:14159
Unable to connect to host 172.16.8.12:14159

why?

this is only because of a little thing -
/tmp file system should be executable on all nodes!!

login as root to all vertica nodes
type this command:
 sudo mount -o remount,exec /tmp

or remove this "noexec" flag from /etc/fstab in /tmp line and remount /tmp

after that run vnetperf again from dbadmin user

[dbadmin@vertica-N1 tmp]$ vnetperf

The maximum recommended rtt latency is 2 milliseconds. The ideal rtt latency is 200 microseconds or less. It is recommended that clock skew be kept to under 1 second.
test              | date                    | node             | index | rtt latency (us)  | clock skew (us)
-------------------------------------------------------------------------------------------------------------------------
latency           | 2018-03-06_10:17:39,795 | 172.16.8.10       | 0     | 374               | -948042
latency           | 2018-03-06_10:17:39,795 | 172.16.8.108      | 1     | 610               | -1996626
latency           | 2018-03-06_10:17:39,795 | 172.16.8.11       | 2     | 407               | -1198531
latency           | 2018-03-06_10:17:39,795 | 172.16.8.12       | 3     | 521               | -1220711
latency           | 2018-03-06_10:17:39,795 | 172.16.8.8        | 4     | 48                | 5
latency           | 2018-03-06_10:17:39,795 | 172.16.8.9        | 5     | 545               | -968135

Comments

Post a Comment

Popular posts from this blog

ORA-27104: system-defined limits for shared memory was misconfigured

I faced this error while trying to restore & recover of a PDB (pluggable database) part of the log file and the solution is described here below: log: initialization parameters used for automatic instance: db_name=CDB db_unique_name=gbux_pitr_PDB1_CDB compatible=12.1.0.2.0 db_block_size=8192 db_files=200 diagnostic_dest=/oracle/app/oracle _system_trig_enabled=FALSE sga_target=1888M processes=200 db_create_file_dest=/oracle/auxilary log_archive_dest_1='location=/oracle/auxilary' enable_pluggable_database=true _clone_one_pdb_recovery=true #No auxiliary parameter file used starting up automatic instance CDB RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 07/31/2016 16:22:20 RMAN-04014: startup failed: ORA-27104: system-defined limits for shared
6 comments
Read more

mount.nfs: backgrounding

if you face this kind of error with your remote NFS: [root@Vertica000 ~]# mount /files/application/Rremote3 mount.nfs: backgrounding "10.0.0.2:/files/application/remoteFiles" mount.nfs: mount options: "bg,hard,nointr,rsize=65536,wsize=65536,tcp,actimeo=0,vers=3,timeo=600,addr=10.0.0.2" look for the problem in the log file: cat /var/log/messages | grep mount  mount to NFS server '10.0.0.2' failed: timed out, retrying Solution: In most of the cases, you have a problem with your iptables in the destination server login as root to dest server (10.0.0.2) in my case and type this command: iptables --flush  the go back to your origin server to try remount the problematic NFS file system of course this is in case nfs server was installed and functioning properly. Good luck.
1 comment
Read more

ora-65035 while create pluggable database from another one

or : ORA-21000: error number argument to raise_application_error of -65035 is out of range Cause: this error caused because of an unrecoverable transaction in the source DB. Solution: 1. either stop and start your pluggable source DB 2. identify the open transaction and kill it if you can. use this query to do so: select * from v$transaction t,v$session  s where t.ses_addr = s.saddr;
Post a Comment
Read more