Standard Instances

Instances of this family are well suited for most applications.

Small Instance

1.7 GB memory
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage (150 GB plus 10 GB root partition)
32-bit platform
I/O Performance: Moderate
API name: m1.small

Large Instance

7.5 GB memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage (2×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
API name: m1.large

Extra Large Instance

15 GB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage (4×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
API name: m1.xlarge

High-Memory Instances

Instances of this family offer large memory sizes for high throughput applications, including database and memory caching applications.

High-Memory Extra Large Instance

17.1 GB of memory
6.5 EC2 Compute Units (2 virtual cores with 3.25 EC2 Compute Units each)
420 GB of instance storage
64-bit platform
I/O Performance: Moderate
API name: m2.xlarge

High-Memory Double Extra Large Instance

34.2 GB of memory
13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each)
850 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.2xlarge

High-Memory Quadruple Extra Large Instance

68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge

High-CPU Instances

Instances of this family have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications.

High-CPU Medium Instance

1.7 GB of memory
5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)
350 GB of instance storage
32-bit platform
I/O Performance: Moderate
API name: c1.medium

High-CPU Extra Large Instance

7 GB of memory
20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: c1.xlarge

Начин на използване:

rdesktop 192.168.1.1

mkdir -p /usr/share/fonts/mynewfonts/

След това прекешираме шрифтовете, а в Debian това става със следната команда:

sudo fc-cache -f -v

И готово

find $LOCATION -name $REQUIRED_FILES -type f -mmin +360 -delete

$LOCATION - път от където да започне търсенето на файловете
$REQUIRED_FILES – име (regex) за търсене на файлове

Вдигането на тунел в ssh не е от най-трудните неща и се постига доста лесно, с една команда:

ssh -f blagomir@casper -L 123:blagomir.com:456 -N

-f означава, че ssh процеса ще се пусне в background
-L 123 – процеса ще слуша на порт 123

Цялата команда се тълкува по следния начин:
ако потребител blagomir на машина casper (тук се пише IP на машината, вместо името й) се свързва през порт 123, той се пренасочва към порт 456 на машина blagomir.com

Можете ли да отговорите какво ще върне всеки alert() докато четете кода, без да го тествате?

if (!("a" in window)) {
    var a = 1;
}
alert(a);

var a = 1,
    b = function a(x) {
        x && a(--x);
    };
alert(a);

function a(x) {
    return x * 2;
}
var a;
alert(a);

function b(x, y, a) {
    arguments[2] = 10;
    alert(a);
}
b(1, 2, 3);

function a() {
    alert(this);
}
a.call(null);

mysqladmin -u root -p PASSWORD

Ако искате да смените вече заложена парола:

mysqladmin -u root -pOLD_PASSWORD password 'NEW_PASSWORD'

Например ако паролата ви е 123 и искате да я смените на 456, това ще изглежда така

mysqladmin -u root -p123 password '456'

Можете да смените паролата и с SQL команда:

USE mysql;
UPDATE user SET password=PASSWORD("NEWPASSWORD") WHERE User='root';
FLUSH privileges;

Започнах по най-стария и лесен начин, а именно:

rm logs/ -r

За около 1 минута load avearage на машината се качи от 1 до 16. Да, тук някой от вас ще кажат, че load-а не е определящ фактор, но все пак е някаква цифра, по която може да се водим за оптималната работа на сървъра.
Значително се усещаше натоварването при работа със сайта. Всичко се случваше изключително бавно, MySQL заявките се изпълняваха за невъзможни времена от сорта на +1 сек.
Опитах да пусна същата команда, но с различен nice:

nice -n 10 rm logs/ -r

Това просто отложи натоварването. След около 10 мин пак имаше проблем с машината и трябваше да търся ново решение. След кратко ровене в google, намерих няколко статии, гласящи, че може да се направи нещо като unlink на самата директория и тя да изчезне заедно с файловете в нея за около секунда Да, но не. При подобно изтриване на директория/файлове, те не се изтриват физически от диска, а просто системата вече не линква към тях. Следователно не се освобождава място на диска. Другият възможен проблем е, че при рестартиране на машината, като се пусне fsck ще се опита да оправи проблемите, а именно да изтрие файловете, към който няма “референции”. Това може да доведе до счупване на цялата файлова система и да си навлечете още по-големи проблеми.

Моят съвет е – изтриите си файловете. Може да отнеме повече време (1-2-3 дни), но ще сте сигурни, че няма да имате проблеми в последствие.