Questions tagged with Compute
Content language: English
Sort by most recent
I have a t4g.xlarge instance type for my production server and have set 200 GiB and IO2 64000 IOPS limit, but am being hit 83000 IOPS and being charged $1200-$1300, so please suggest to me how to get the cost down suggest me a way to optimize it.
# when I do this command "agc account activate", the following error was generated:
==\\
2023-02-18T22:00:44-08:00 𝒊 Activating AGC with bucket '' and VPC ''
Bootstrapping CDK... [--o-] 2.0s
2023-02-18T22:00:47-08:00 ✘ '\\\\wsl.localhost\Ubuntu\home\jeffzz\\.agc\cdk'
2023-02-18T22:00:47-08:00 ✘ CMD.EXE was started with the above path as the current directory.
2023-02-18T22:00:47-08:00 ✘ UNC paths are not supported. Defaulting to Windows directory.
2023-02-18T22:00:47-08:00 ✘ The system cannot find the path specified.
2023-02-18T22:00:47-08:00 ✘ error="exit status 1"
Error: an error occurred invoking 'account activate'
with variables: {bucketName: vpcId: publicSubnets:false customTags:map[] subnets:[] amiId:}
caused by: exit status 1
==\\
would greatly appreciate any help!
I have a problem with my socket server built with webSocketApi. everything works fine unless the decive loose its connectivity, close the conection and someone try to send a message to this device.
The websocketApi does not throw any error and if i try to get the connection via @connections API, the SocketApi stll giving like the device is connected untill the idle timeout come. And then it's impossible to detect from my side this case to enqueue the message to be sent later.
I'm thinking about using the keep alive client ping to trace the last ping and close the connection manually if the last ping is older than 30 secs or something like this.
Has someone any solution for this case or this is the normal way to works?
thank you.
I created several EC2 instances running Amazon Linux 2 a few weeks ago, all with SSH access. A few days ago, one instance stopped allowing SSH access with the message `ec2-user@10.0.145.93: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).` - an error message I'd expect to see if my SSH keys were invalid.
The instance is still running, and the cron jobs I configured on it are still running as normal. I don't have serial console to the instance but I was able to create an AMI and then a VMDK from the instance in its current state and mount the filesystem to attempt to figure out what's wrong. As far as I can tell all the SSH configuration is still as I configured it: all the correct keys are still present in `~/.ssh/authorized_keys` and the contents of `/etc/ssh/` are identical to a clean AL2 install.
The security groups haven't changed (they still allow SSH access) and the SSHD config is the same, so what is going on?
Trying to connect to a IoT thing via code to simulate a device with Python. This code was working before and now I'm getting this error.
The code is straight forward.
```
import time as t
from datetime import datetime
import AWSIoTPythonSDK.MQTTLib as AWSIoTPyMQTT
def helloworld(self, params, packet):
print(packet.payload)
myCLIENT = AWSIoTPyMQTT.AWSIoTMQTTClient('test_thing')
myCLIENT.configureEndpoint('myEndPoint', 8883)
myCLIENT.configureCredentials("Path to AmazonRootCA1.pem", "Path to private.pem.key", "Path to certificate.pem.crt")
myCLIENT.configureOfflinePublishQueueing(-1) # Infinite offline Publish queueing
myCLIENT.configureDrainingFrequency(2) # Draining: 2 Hz
myCLIENT.configureConnectDisconnectTimeout(10) # 10 sec
myCLIENT.configureMQTTOperationTimeout(5) # 5 sec
print('Connecting...')
myCLIENT.connect()
print('Connected')
def loop():
temperature = 20
humidity = 67
while True:
curr_dt = datetime.now()
myCLIENT.publish(
topic='test_thing/test',
payload='{"timestamp": ' + str(int(round(curr_dt.timestamp()))) + ', "temperature": ' + str(temperature) + ', "humidity":' + str(humidity)+', "project_id": 1}',
QoS=1)
if temperature < 25:
temperature += 0.01
humidity += 0.005
else:
temperature -= 0.01
humidity -= 0.005
t.sleep(1)
if __name__ == '__main__':
try:
loop()
except KeyboardInterrupt:
myCLIENT.disconnect()
```
And I'm getting this error when trying to connect
```
test_thing.py:24: in <module>
myCLIENT.connect()
..\..\Anaconda3\lib\site-packages\AWSIoTPythonSDK\MQTTLib.py:355: in connect
return self._mqttCore.connect(keepAliveIntervalSecond)
..\..\Anaconda3\lib\site-packages\AWSIoTPythonSDK\core\protocol\mqttCore.py:282: in connect
self._pahoClient.connect(self._host, self._port, keepAliveInterval) # Throw exception...
..\..\Anaconda3\lib\site-packages\AWSIoTPythonSDK\core\protocol\paho\client.py:655: in connect
return self.reconnect()
..\..\Anaconda3\lib\site-packages\AWSIoTPythonSDK\core\protocol\paho\client.py:807: in reconnect
self._sock.setblocking(0)
E OSError: [WinError 10038] An operation was attempted on something that is not a socket
```
Any ideas where the problem might be?
There is not an option to "Force Stop" instance.
Instance has been in "stopping" status for 10 minutes.
Please advise on next steps.
thank you
Getting below mentioned Warning Messages while trying to upgrade from CEDR to DRS in Linux System installed with AMI 2.0.
```
python3 cloudendure_to_drs_upgrade_tool.py start-upgrade --api-token <API Token> --project-id <ProjectID> —aws-access-key-id <AccessKey> —aws-secret-access-key <SecretKey> --import-blueprint --import-replication-configuration --import-test-snapshot
Running the CloudEndure to DRS Upgrade tool.
Connecting to the CloudEndure Console... Finished.
Warnings:
- Unable to detect if the Machine's operating system is supported by DRS.
Refer to DRS documentation for the list of supported operating systems (UnableToDetermineOperatingSystemSupport)
- Unencrypted volumes are not supported in DRS.
It is recommended to set an explicit encryption key in your Replication settings prior to performing the upgrade.
Machines with no volume encryption configured will be converted to use the default EBS encryption key in DRS. (UnencryptedVolumesUnsupported)
There are warnings for this machine. Would you like to continue? [Y/n]:n
```
As per below mentioned AWS Doc AL 2.0 is supported by DRS:
[https://docs.aws.amazon.com/drs/latest/userguide/Supported-Operating-Systems.html
]()
Moreover I have set Default key for EBS Volume Encryption in both CEDR and DRS Service.
What should I do fix these warning signs besides the steps which I have taken?
I'm currently running a 2019 windows instance on macOS as I am running software that I can't use on macOS on my Windows Instance. Whenever I want to connect to my EC2 instance, I have to download a new RDP file because it won't launch automatically even though I've downloaded the SSM Agent onto it. Is there anyway I can get it to connect to my instance automatically instead of me having to download a new RDP file and manually entering the password each time?
I am a new AWS Snowball family user working on a Edge Compute Optimized Snowball. I have followed the steps in the tutorial video here (https://www.youtube.com/watch?v=GDDJgQCtPRg) without any issues. Now that my instances are set up however, I am unable to access them and they continue to fail the reachability check.
Troubleshooting steps included the following:
-Trying different Operating System images (currently Windows 10 and CentOS7)
-Stopping and restarting the instances
-Restarting the SnowballEdge
-Changing instance types
-Enabling/Disabling key pairs
-Changing Image volume size
Because I am using AWS OpsHub to manage the SnowballEdge, it does not appear I am able to take console screenshots or pull logs in the same manner that is recommended for troubleshooting with AWS Console.
Appreciate any insight into the matter.
Hi,
I set up security group for the instance, as you know I added rules for the ports over there
Do I need to enable ufw ? When I did 'sudo ufw status', it says 'status inactive'
Thanks
Sung
I have a process called server (developed in rust, but I don't think that is critical), it should run with about constant load 24/7. The CPU load for the process is in the sustainable zone. The system is running Ubuntu 20.04
Yesterday it was killed with an out of memory message. Looking at kern.log, I can see that there are a number of messages before the process was killed, the first was "unattended-upgr invoked oom-killer: gfp_mask=0x1100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0"
```
Feb 10 07:01:38 ip- kernel: [1133764.101038] unattended-upgr invoked oom-killer: gfp_mask=0x1100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0
Feb 10 07:01:38 ip- kernel: [1133764.101047] CPU: 0 PID: 640430 Comm: unattended-upgr Not tainted 5.15.0-1028-aws #32~20.04.1-Ubuntu
Feb 10 07:01:38 ip- kernel: [1133764.101050] Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
```
Looking at the memory usage you can see that my server app is using 155MB RAM. Surprisingly snapd is using 184MB, amazon-ssm-agen 307MB, and ssm-agent-worke 310MB
```
Feb 10 07:01:38 ip- kernel: [1133764.101272] Tasks state (memory values in pages):
Feb 10 07:01:38 ip- kernel: [1133764.101272] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Feb 10 07:01:38 ip- kernel: [1133764.101275] [ 266] 0 266 70052 4501 98304 0 -1000 multipathd
Feb 10 07:01:38 ip- kernel: [1133764.101279] [ 441] 0 441 59353 451 90112 0 0 accounts-daemon
Feb 10 07:01:38 ip- kernel: [1133764.101281] [ 442] 0 442 637 166 40960 0 0 acpid
Feb 10 07:01:38 ip- kernel: [1133764.101283] [ 446] 0 446 2137 582 53248 0 0 cron
Feb 10 07:01:38 ip- kernel: [1133764.101286] [ 449] 103 449 1982 753 61440 0 -900 dbus-daemon
Feb 10 07:01:38 ip- kernel: [1133764.101288] [ 458] 0 458 7469 2827 94208 0 0 networkd-dispat
Feb 10 07:01:38 ip- kernel: [1133764.101290] [ 459] 0 459 58181 224 81920 0 0 polkitd
Feb 10 07:01:38 ip- kernel: [1133764.101292] [ 464] 0 464 307844 1343 180224 0 0 amazon-ssm-agen
Feb 10 07:01:38 ip- kernel: [1133764.101294] [ 470] 0 470 4418 867 69632 0 0 systemd-logind
Feb 10 07:01:38 ip- kernel: [1133764.101297] [ 473] 0 473 98274 773 122880 0 0 udisksd
Feb 10 07:01:38 ip- kernel: [1133764.101298] [ 474] 0 474 951 455 49152 0 0 atd
Feb 10 07:01:38 ip- kernel: [1133764.101300] [ 498] 0 498 60334 581 106496 0 0 ModemManager
Feb 10 07:01:38 ip- kernel: [1133764.101302] [ 501] 0 501 1840 435 49152 0 0 agetty
Feb 10 07:01:38 ip- kernel: [1133764.101304] [ 515] 0 515 1459 382 45056 0 0 agetty
Feb 10 07:01:38 ip- kernel: [1133764.101306] [ 556] 0 556 27032 2749 114688 0 0 unattended-upgr
Feb 10 07:01:38 ip- kernel: [1133764.101308] [ 639] 0 639 3046 704 61440 0 -1000 sshd
Feb 10 07:01:38 ip- kernel: [1133764.101310] [ 788] 0 788 310204 1846 192512 0 0 ssm-agent-worke
Feb 10 07:01:38 ip- kernel: [1133764.101312] [ 8869] 0 8869 2397 949 57344 0 -1000 systemd-udevd
Feb 10 07:01:38 ip- kernel: [1133764.101314] [ 11347] 100 11347 6817 875 73728 0 0 systemd-network
Feb 10 07:01:38 ip- kernel: [1133764.101316] [ 11355] 101 11355 6137 1403 81920 0 0 systemd-resolve
Feb 10 07:01:38 ip- kernel: [1133764.101318] [ 11359] 0 11359 17149 1077 159744 0 -250 systemd-journal
Feb 10 07:01:38 ip- kernel: [1133764.101320] [ 11463] 102 11463 22721 511 86016 0 0 systemd-timesyn
Feb 10 07:01:38 ip- kernel: [1133764.101323] [ 11642] 104 11642 56125 343 81920 0 0 rsyslogd
Feb 10 07:01:38 ip- kernel: [1133764.101325] [ 190175] 1000 190175 4732 413 73728 0 0 systemd
Feb 10 07:01:38 ip- kernel: [1133764.101327] [ 190176] 1000 190176 42626 1132 94208 0 0 (sd-pam)
Feb 10 07:01:38 ip- kernel: [1133764.101329] [ 191381] 0 191381 184017 4350 249856 0 -900 snapd
Feb 10 07:01:38 ip- kernel: [1133764.101332] [ 355693] 1000 355693 2164 983 61440 0 0 tmux: server
Feb 10 07:01:38 ip- kernel: [1133764.101334] [ 355694] 1000 355694 2506 872 53248 0 0 bash
Feb 10 07:01:38 ip- kernel: [1133764.101336] [ 611154] 0 611154 3453 978 65536 0 0 sshd
Feb 10 07:01:38 ip- kernel: [1133764.101338] [ 611258] 1000 611258 3574 982 65536 0 0 sshd
Feb 10 07:01:38 ip- kernel: [1133764.101340] [ 611259] 1000 611259 2510 901 53248 0 0 bash
Feb 10 07:01:38 ip- kernel: [1133764.101342] [ 622945] 0 622945 3452 977 65536 0 0 sshd
Feb 10 07:01:38 ip- kernel: [1133764.101343] [ 623052] 1000 623052 3485 819 65536 0 0 sshd
Feb 10 07:01:38 ip- kernel: [1133764.101345] [ 623054] 1000 623054 3038 1483 57344 0 0 bash
Feb 10 07:01:38 ip- kernel: [1133764.101347] [ 629386] 1000 629386 155370 35002 393216 0 0 server
Feb 10 07:01:38 ip- kernel: [1133764.101349] [ 638483] 0 638483 654 434 45056 0 0 apt.systemd.dai
Feb 10 07:01:38 ip- kernel: [1133764.101351] [ 638487] 0 638487 654 434 45056 0 0 apt.systemd.dai
Feb 10 07:01:38 ip- kernel: [1133764.101353] [ 638521] 0 638521 81187 14207 425984 0 0 unattended-upgr
Feb 10 07:01:38 ip- kernel: [1133764.101355] [ 640399] 0 640399 70904 836 151552 0 0 packagekitd
Feb 10 07:01:38 ip- kernel: [1133764.101357] [ 640430] 0 640430 92707 24658 425984 0 0 unattended-upgr
```
Immediately after this, my process was killed:
```
Feb 10 07:01:38 ip- kernel: [1133764.101359] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-296.scope,task=server,pid=629386,uid=1000
Feb 10 07:01:38 ip- kernel: [1133764.101385] Out of memory: Killed process 629386 (server) total-vm:621480kB, anon-rss:138304kB, file-rss:1704kB, shmem-rss:0kB, UID:1000 pgtables:384kB oom_score_adj:0
```
Why was my process killed? It was not the reason that the system ran out of memory. How much of the available memory can I use on a Lightsail server?
I moved the Lightsail instance of volume 320GB to EC2 and made a new instance. Then I resized the EBS volume from 320 GB to 50GB. Detached both the volume at first and reattached 50 GB volume only. After starting the instance instance status check is failed.
