Изпечатай

[backinblack]

Май намерих решение!

В my.cnf конфиг файла query_cache_limit беше 1М и го поправих на 1024М и сега пак си пълни почти до край, но веднага освобождава като стартирам нещо друго което изисква ресурс.
Защо работи така и не разбрах, но за сега дава резултат. Имаше и някакви други съвети за лимитиране на рама, но като го вкарам реда и не стартира MySQL-а! Май там ще да е заигравката.

[d0ni]

Съмнявам се това да ти е оправило проблема. query_cache_limit указва колко най-много може да е голям резултатът от дадено query за да бъде кеширано. 1 GB е ужасно много.

[Acho]

Намалявай го тогава, тоя параметър.

[backinblack]

На 2 виртуалки, едната ми е с графична среда, а другата без с почти един и същи софтуер на тях и с един и същ проблем! Пробвах и с 3ГБ рам и трите ГБ се пълнят до над 90% и чак уебмина спира да работи! След рестарт се напълват за около 20 минути без нищо да се работи на тях. На тази която е с графична среда, като отворя с 300 зора браузер с няколко таба и пада от 1,6 от 2 до под 1ГБ и като затворя браузера пада на около 500 и пак почва да пълни до около 90+% от 1-2-3ГБ!
От снощи и на двете промених параметъра от 1М на 1024М и сега пълни до към 70%, но като отворя таск менажера или браузере и веднага пада до нормалното, без 3-4 минути "раздвижване" както преди.
Не го разбирам това, но рових в нета за оптимизиране дб сървъра и имаше и други параметри посочени дето трябваше да вкарам редове, но след като вкарам реда и стойностите не ми стартира майескуела.
Сега смятам да пробвам с по-малка стойност, примерно 512М да видя какво ще е положението.

[jet]

Май намерих решение!

В my.cnf конфиг файла query_cache_limit беше 1М и го поправих на 1024М и сега пак си пълни почти до край, но веднага освобождава като стартирам нещо друго което изисква ресурс.
Защо работи така и не разбрах, но за сега дава резултат. Имаше и някакви други съвети за лимитиране на рама, но като го вкарам реда и не стартира MySQL-а! Май там ще да е заигравката.

това мяза на калпаво направени SQL заявки, сигурно дъмпиш цялата база даже за малки търсения.

[backinblack]

Това се появи след като инсталирах E-Groupware и ме съмнява, че е от него, но реално не се ползва, а само си експериментирам с него, но пък с него експериментирах и преди доста време когато бях още с 10.04 и нямах такива проблеми! Близо 1 година и повече не бях се занимавал с него. В момента и на двете виртуалки е то и по един уордпрес, като на едната има и графична среда.

Междувременно, с параметър 512М е по-зле положението на сървъра, а на другата, с графичната среда, не забелязвам разлика.
На сървъра има и нагласен мейл сървър с постфикс и с 1024М в покой си стои стабилно закотвен на 600-630МБ рам и като го разцъквам не мърда. Намалих му дори рама на 1ГБ и е 6+ за сега.

[theshit]

На мен едно приятелче, което се занимава ми помага донякъде със Linux сървъра (по принцип залагам на Unix, но Linux ме изумява с всеки изминал ден), и това което съм забелязал е една интересна команда в крон-а на root-a

Код:

*/45 * * * * sh /root/check.sh >/dev/null 2>&1

на 45 минути ми изпълнява chek.sh баш скрипт в директорията на root, а скрипта е следния

Код:

#!/bin/bash
sync; echo 3 > /proc/sys/vm/drop_caches

като изпълня командата cat /proc/sys/vm/drop_caches, излиза само цифрата 3

Код:

3

а при man drop_caches излиа и "manual page" с информация

NAME

drop_caches - drop clean caches from memory (Linux 2.6.16+)

DESCRIPTION

  The  drop_caches  command  can display values from /proc/meminfo and
  can write specified value to /proc/sys/vm/drop_caches, valid  values
  are:
    0 # default
    1 # free pagecache
    2 # free dentries, inodes
    3 # free pagecache, dentries, inodes

Според което стигам до извода, че по-голямата цифра - чисти повече от кешираното в паметта (в случая 3 е макс).
И определено като стартирам скрипта ръчно (./check.sh) ми се освобождава половината RAM, от г/д 380MB заета, пада на  на 215MB.

От други приятели, които разбират знам, че да не се притеснявам за рамта, но кешираното си стои и после почва да хвърля на SWAP-а в диска, което не ми харесва - да драска на диска вместо на платковата памет. И мисля, че може да ви е от полза. Да си сетнете един такъв крон в  root юзъра, да ви освобождава рам на определено време, в зависимост от това, колко интензивно използвате "десктопа" си.

Аз съм с Linux Debian 7.4 wheezy и мисля, че са доста идентични с Ubuntu и сигурно имате drop_cache, за другите просто потърсете в Google за съответната дистрибуция.

Надявам се да съм ви бил полезен 


Пс. Разбирам идеята да се кешира всичко ... хора, които разбират са ми обяснявали, че нещо което вече е кеширано ще зарежда много по-бързо и затова Линукса си е и бърз. Но понякога не откривам смисъл. Например ако си пуснал Скайп и ти е заел 30 МБ кеш, и после като го затвориш и го пуснеш - ще зареди много по-бързо - втория път, защото вече е в кеша. Но пък ако съм инсталирал Скайп преди малко, инсталационните му файлове също остават кеширани, което значи че ако го инсталирам пак преди да  рестартирам, той ще се инсталира по-бързо, понеже вече е натоварен в кеша, но като се замисли реално човек - няма да инсталира Скайп през 2 минути, за да му е нужно да стои инсталационното кеширано в рамта и вместо да го освободи да почва да хвърля в SWAP-a, нз така мисля аз, може да греша и да ви подвеждам. Всеки сам си избира конфигурацията според нуждите и по собствена преценка.

[jet]

Когато дотрябва памет, тези кешираните области се изпразват, така, че няма опасност да swap-ва.

[backinblack]

И аз знам, че така действа кеша е от незаета рам файда няма, но на няколко пъти обясних, че проблема е по-друг! Проблема е, че не освобождава веднага и много трудно стартира приложение, та чак и крашва и така с малко повече упорство от около 3-5 минути и рама пада до където трябва да бъде и всичко заработва бързо и както си трябва и като се остави в един момент в покой и пак почва да пълни до край и пак така до безкрай.

Но, с редактирането на онзи параметър в базата, вече го нямам този проблем.