Connection Limitation

Hi, Is Aerospike provides limiting in connections. suppose client connections reach above 60K then they should go in queue and should not process until value goes lower than 60K.

You’ll fail to connect. Feel free to increase it, but don’t go above open file limits.

I check when spikes comes in backend server it send more request to Aerospike Cluster sometimes i observe when migration in progress that time query read, write time too slow and CPU goes high to process request, but that time asd does not crashed. reached connection on Aerospike one machine = 45K to 60K (read + write) so how can i stable machine during migration. I am using aws i3.2xlarge machine and aerospike version is 3.13 if i set "asadm -e “asinfo -v ‘set-config:context=service;write-duplicate-resolution-disable=true’” if load gone high during migration it will start more latency. any other way to stablize aerospike during migration please feel free to share… Thanks.

Could you share your aerospike.conf?

# Aerospike database configuration file for deployments using mesh heartbeats.

service {
	user root
	group root
	paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1.
	pidfile /var/run/aerospike/asd.pid
  service-threads 4
  transaction-queues 4
  transaction-threads-per-queue 4
  proto-fd-max 100000
  #migrate-xmit-hwm 5
  #migrate-xmit-lwm 2
  #migrate-xmit-priority 20
  #migrate-read-priority 10
  migrate-threads 2
  migrate-max-num-incoming 64
}

logging {
	# Log file must be an absolute path.
	file /var/log/aerospike/aerospike.log {
		context any info
	}
}

network {
	service {
		address any
		port 3000
	}

	heartbeat {
		mode mesh
		port 3002 # Heartbeat port for this node.

		# List one or more other nodes, one ip-address & port per line:
		mesh-seed-address-port 10.0.3.3 3002
		mesh-seed-address-port 10.0.2.2 3002
		mesh-seed-address-port 10.0.5.1 3002

		interval 250
		timeout 10
	}

	fabric {
		port 3001
	}

	info {
		port 3003
	}
}

namespace test {
	replication-factor 2
	memory-size 10M
	default-ttl 30d # 30 days, use 0 to never expire/evict.

	storage-engine memory
}

namespace profiles {
      memory-size 55G         # Maximum memory allocation for primary
                                  # and secondary indexes.
      storage-engine device {     # Configure the storage-engine to use persistence
          device /dev/data/data     # bcache device.
          # device /dev/bcache1   # (optional) another bcache device.
          write-block-size 1M     # adjust block size to make it efficient for SSDs.
      }
}

What version of Aerospike are you running?

How many nodes?

Version = Aerospike Community Edition build 3.13.0.1 3 nodes are running…

If you are having latency problems during migrations then you should probably shouldn’t increase the aggressiveness of migrations.

I suggest leaving these at the default values (migrate-threads 1 and migrate-max-num-incoming 4).

In addition your service-threads and transaction-queues configurations will likely not be able to utilize your i3.2xlarge. We typically recommend matching this to the number of cores (8 for i3.2xlarge), which is the default if they are not present in the config since 3.12.0.