Instanță AWS de producție: Avem o instanță m5 ec2 nitro care are nevoie de optimizare a interogărilor. Cu toate acestea, suntem într-o criză de timp și am decis să aruncăm temporar memorie și stocare până când vom putea finaliza optimizarea interogărilor.(Ne cerem scuze în avans)
Există 50 GB pe unu Volumul EBS (/dev/sda1) si altul 50 GB pe un al doilea volum (/dev/sdf). Din câte îmi dau seama, EC2 folosește doar unul dintre volumele de 50 GB, dev/sda1.
Versiunea Linux Kernal: 4.4.0-1128-aws
32 GB RAM (M5a.2xlarge)
Al nostru /dev/nvme0n1p1 | (/tmp) directorul se umple creând o eroare SQL 28 Fără spațiu pe disc și dorim să creștem dimensiunea /tmp director din 20 GB până la 50 GB. în timp ce optimizăm interogările pentru a reduce dimensiunile fișierelor de baze de date temporare (.MAI) stocate în /tmp
Unde sunt: În mediul nostru de testare/EC2 (de asemenea, un M5.2xlarge) am reușit să măresc dimensiunea volumului la 100 GB și am urmat pașii din https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
- Asta se vede când alerg lsblk
NUME MAJ:MIN RM DIMENSIUNE RO TIP PUNCT DE MONTARE
nvme0n1 259:0 0 100G 0 disc
âânvme0n1p1 259:1 0 20G 0 parte /
âânvme0n1p2 259:2 0 2G 0 parte [SWAP]
âânvme0n1p3 259:3 0 28G 0 parte
ââvg_xxx-logs 251:0 0 8G 0 lvm /var/log
ââvg_xxx-app 251:1 0 19G 0 lvm /home/xxx
Iată ce se arată când rulez df -hT:
Tip sistem de fișiere Dimensiune Utilizată Avail Use% Montat pe
udev devtmpfs 16G 0 16G 0% /dev
tmpfs tmpfs 3.1G 183M 3.0G 6% /run
/dev/nvme0n1p1 ext4 20G 8.6G 11G 45% /
tmpfs tmpfs 16G 0 16G 0% /dev/shm
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/loop0 squashfs 44M 44M 0 100% /snap/certbot/1788
/dev/loop1 squashfs 111M 111M 0 100% /snap/core/12834
/dev/loop3 squashfs 62M 62M 0 100% /snap/core20/1434
/dev/loop5 squashfs 56M 56M 0 100% /snap/core18/2409
/dev/loop4 squashfs 25M 25M 0 100% /snap/amazon-ssm-agent/4046
/dev/loop2 squashfs 56M 56M 0 100% /snap/core18/2284
/dev/mapper/vg_xxx-logs xfs 8.0G 362M 7.7G 5% /var/log
/dev/loop6 squashfs 26M 26M 0 100% /snap/amazon-ssm-agent/5656
/dev/loop8 squashfs 44M 44M 0 100% /snap/certbot/2035
/dev/loop7 squashfs 62M 62M 0 100% /snap/core20/1328
/dev/mapper/vg_xxx-app xfs 19G 4.7G 15G 25% /home/xxx
tmpfs tmpfs 3.1G 0 3.1G 0% /run/user/1000
tmpfs tmpfs 3.1G 0 3.1G 0% /run/user/1001
După cum puteți vedea, arată asta nvme0n1 are 100 GB disponibile, totuși, cele 3 partiții sunt încă egale 50 GB. când ajung la pasul 7 din documentația AWS despre extinderea sistemului de fișiere pentru a ocupa noul spațiu de volum adăugat, primesc următoarele:
ubuntu@ip-xx-xx-xx-xxx:~$ **sudo resize2fs /dev/nvme0n1p1**
resize2fs 1.42.13 (17-mai-2015)
**Sistemul de fișiere are deja 5242619 (4k) blocuri. Nimic de făcut!**
Am un sistem de fișiere ext4 (cu excepția faptului că văd două lvms în subdirectorul nvme0n1p3 dar nu cred că asta schimbă nimic) și am încercat parte de creștere, despărțit, dar aceste soluții găsite online sunt în general pentru Ubuntu și nu în mod specific pentru volumele EC2 EBS, așa că nu vreau să mă îndepărtez prea mult de ceea ce ar trebui să fie o soluție furnizată de AWS pe care nu o pot găsi. Acestea fiind spuse, acestea au produs și mesaje de eroare care spuneau că unitatea/directorul era în uz.
Înțeleg că AWS EBS permite unui ec2 să mărească dimensiunea volumului și apoi să extindă sistemul de fișiere fără a opri instanța sau a demonta dispozitivul care este extins. Cu toate acestea, nu am reușit să fac același lucru când opresc instanța de staging pe care testez. Sunt deschis să opresc instanța pentru a face acest lucru, totuși, aș prefera să o fac fără a demonta dispozitivul și/sau a opri instanța.
De asemenea, pot face upgrade instanța pentru a oferi mai multă RAM dacă este necesar, dar mai întâi ar trebui să extind sistemul de fișiere.
Orice ajutor este apreciat!
