dimensioni crescenti di / tmp su istanze EC2

8

Sto eseguendo un server Ubuntu su ebs EC2 e la mia applicazione necessita di molto spazio temporaneo su disco, allocato in / tmp. Tuttavia, su ec2 l'unità root che contiene anche / tmp è piuttosto piccola, circa 10 GB. Tutto lo spazio su disco rimanente è montato in / mnt. Di conseguenza, la mia applicazione restituisce errori di "spazio su disco insufficiente", poiché / tmp sembra essere pieno.

Qual è il modo migliore per risolvere questo problema? Una cosa che mi viene in mente è creare / mnt / tmp e creare un collegamento simbolico

/tmp --> /mnt/tmp

Tuttavia, sono un po 'riluttante a scherzare con qualcosa che viene utilizzato da tanti programmi e strumenti Linux. Non sono sicuro se ogni programma risolverà correttamente il collegamento simbolico e non sono sicuro di cosa significherebbe per le prestazioni.

amazon-ec2

— Jeroen
fonte

2

I montaggi di bind significano non dover ricollegare.

— Ignacio Vazquez-Abrams,

5

Con le immagini supportate da EBS, l'archiviazione effimera è ancora disponibile, per impostazione predefinita non è mappata come dispositivo a blocchi (come nelle immagini dell'istanza)

Il dottore Amazon è qui , e c'è un post utile, qui

In breve: è possibile specificare questo mapping sulla riga di comando all'avvio dell'immagine, quindi montarlo come volume normale su /dev/sd[x]. Oppure, se esegui il rollup della tua AMI, puoi eseguire il mapping in quella AMI in modo che tutte le immagini lanciate da essa possano accedervi dall'inizio.

Il collegamento simbolico /tmpfunzionerà, ma non lo consiglierei in questo caso, dove hai una grande quantità di spazio di archiviazione temporaneo in uso. Una volta disponibile la mappatura del dispositivo, è possibile montare il dispositivo come /tmpin /etc/fstab.

Con una piccola istanza, dovresti avere 150 GB di store di istanze disponibili gratuitamente. Va da sé che questo archivio si interrompe quando l'istanza si riavvia. Se il tuo utilizzo non è temporaneo, devi creare il tuo nuovo volume EBS e montarlo in quel modo.

— SmallClanger
fonte

1

Perché il collegamento simbolico non è raccomandato? Ad esempio, se voglio mettere entrambi / var / tmp e / var / log nella mia memoria effimera, posso montare la memoria come / mnt e collegare simbolicamente entrambe le directory lì.

— j0nes,

Buon punto. Stavo pensando a questo caso specifico, basato sul presupposto che l'OP stesse considerando di ricollegare alla partizione principale. Chiarirò la mia risposta.

— SmallClanger

1

È possibile associare il punto di montaggio / tmp a / mnt / tmp:

sudo mount -B / tmp / mnt / tmp

— hithwen
fonte

2

Questi comandi mi guardano indietro. Penso che tu abbia scambiato i due nomi di directory.

— Kasperd,

0

Il collegamento simbolico come suggerito nella domanda non è una soluzione così negativa. Ma è necessario prestare particolare attenzione. Solo per consolidare i passaggi precisi coinvolti nel montaggio del volume sono:

1) Crea nuovo volume nella console AWS. Allegalo all'istanza.

2) Formattalo e montalo sotto diciamo /mnt/vol1

3) Pulisci il più /tmppossibile.

4) mkdir /mnt/vol1/tmp && mv /tmp/* /mnt/ && rmdir /tmp && ln -s /mnt/vol1/tmp /tmp

— Murphy
fonte

Spostare i file nella nuova directory non otterrà il risultato desiderato per nessun file attualmente aperto. Vorrei invece riavviare, poiché i programmi non possono aspettarsi che i file /tmpsopravvivano al riavvio.

— Kasperd,