KRHD: IP посетителя - это именно REMOTE_ADDR.
Если вам для чего-то (например, логов) понадобилось ещё что-то, что можно узнать о клиенте - пишите всё, что найдёте. Например, весь $_SERVER.
Давно ovz не тыкал, не очень в курсе, как там сейчас.
По идее контейнеры мигрируются на другую железку, на этой обновляется ядро, железка ребутается, контейнеры мигрируются обратно.
АртемЪ: какой профиль нагрузки на диск? Раздача торрентов типично даёт много чтения, но блоки-то крупные и хорошо работает опережающее чтение.
Например далеко уже несвежий тест: fcenter.ru/online/hardarticles/hdd/31053
Даже на тяжелейшем многопоточном iometer уже за 50 мегабит у всех участников, а у некоторых и за 150.
И это на мелких блоках очень далеко друг от друга. А торренты раздаются блоками по несколько мегабайт, да ещё нередко одни и те же блоки - привет кэшу ОС.
2,5" диски компактнее, поэтому seek у них обычно быстрее. А меньшая длина дорожки за прошедшие года вполне компенсирована увеличенной плотностью записи.
Создаёте один мост, в который добавляете реальную сетевую карту сервера и свои виртуалки. IP назнаете там где они нужны. Нужен в виртуалке - в самой виртуалке и назначаете. Не забудьте что-нибудь оставить для связи с хостовой системой.
Виртуалки будут думать, что они находятся в одном L2 сегменте. Может, вся стойка к нему же подключена.
Смотря чем и как конвертировать.
Если в конце диска есть достаточно места - то таблица разделов заменяется элементарно без потери данных. Всего-то и надо, запомнить текущую разметку диска, создать заголовки GPT, создать разделы по тем же LBA-блокам.
Указанная статья - именно про without data loss. С потерей - просто размечаете GPT как будто на пустом диске и всё.
Это кусок multipart/form-data.
Вы уверены, что Content-Type HTTP-запроса (самого запроса, не multipart/form-data тела запроса) указан как text/xml?
Если там указан нормальный multipart - посмотрите из $_FILES. Этот файлик должен быть там.
Нет, никаких хешей. Для btree в целом характерен поиск слева, без разницы, уникальный он, первичный или ещё какой. Для поиска по a=5 and b=6 подойдут индексы по a& b, b & a, a & b & c. Но для поиска по b = 6 and c = 2 индекс a & b & c не подходит, а b & a будет использовать только часть индекса. Это, кстати, будет видно в explain по длине key_len
Вот вроде бы неплохая статья о составных индексах: habrahabr.ru/post/70640
Rentast: многосокетность - смотреть на Scalability (1S Only = только 1 сокет), Max CPU Configuration и количество QPI - именно эта шина сейчас отвечает за коммуникацию между процессорами.
> Неужели кто-то в реале 5 лет назад сажал их с памятью больше 32GB?
А почему бы и нет? Для тех же СУБД 32гб памяти - это совсем даже немного. Побольше данных в памяти - значительно меньше работы куда более медленным дискам. А ведь в те времена SSD ещё не были распространённым явлением и сравнивать приходится именно с HDD.
И ещё какие-нибудь задачи, где надо именно много памяти, но вычислительной нагрузки немного. Key-value какие-нибудь хранилища типа Redis, например.
Ну ethernet есть. 10/100мбит/с. А теперь попробуйте через него прокачать сколько-нибудь данных. И посмотрите, осталось ли у CPU время хоть на что-нибудь ещё.
Теперь сравните полученную скорость с тем, что вы можете прочитать с одного внешнего USB-диска. Во сколько раз цифра получилась меньше? В 4? В 5? Или повезло и всего лишь в 3 раза?
Затем вспомним, что чипа на raspberry ethernet банально не умеет. Сеть сделана через usb-сетевушку. А USB-хост только один. Т.е. диски и сеть будут драться за один и тот же ресурс.
Ладно, останем на секунду от медлительной сети на малинке. Посчитаем на пальцах без учёта ограничения по CPU.
100мбит/с сеть = это максимум 12мб/с передачи по сети (хотя 96мбит/с - это фантастика, в реальности поменьше).
USB2.0 - потолок 30-35мб/с (это реально, а не теоретические 480мбит/с)
Как думаете, будет толк от второго порта USB2.0?
Так я же и говорю: приведите в нормальную форму. Если что, это технический термин реляционных СУБД.
Искать реализацию связей многие-ко-многим, делается через отдельную таблицу связей. Описан много где.
JOIN /**/ ON TRUE - это и будет декартово произведение. Обычно выглядит ошибкой, поэтому оставляю комментарий, что именно так и задумано.
Вообще-то, как запоздало сообразил, можно было бы написать CROSS JOIN.
1) см. ссылку из моего ответа. Там весь ответ по профилированию.
2) почему вы не видите запрос? Вот он запрос: SELECT `mytime` FROM `date` WHERE `mytime` BETWEEN a=:a AND b=:b
PDO заменяет именованные параметры, начинающиеся на символ двоеточия или позиционные параметры, задаваемые через символ ?
Итого: SELECT `mytime` FROM `date` WHERE `mytime` BETWEEN a='2007-08-09 01:00:00' AND b='2007-08-09 08:00:00'
3) а зачем вам профилирование, если вы банального не знаете? Начните по порядку с основ программирования. В частности, отсюда: php.net/manual/en/functions.arguments.php#function...
LESHIY_ODESSA: и всё-таки raid - это обычно raid. И в этом режиме TRIM опять не работает, вроде только интел в последние года добавил поддержку трима в режиме рейда.
Сколько можно переназначить - на усмотрение производителя. Для 1тб сигейтов допустимо порядка 3000 релокейтов, потом признают гарантийным.
Но это релокейтов по смарту, а не бедов. Бедов должно быть ровно ноль. Всегда, по всей адресуемой поверхности пластин.
Раз диск не заменил блок самостоятельно - этому диску ничего хранить больше нельзя. А уж сотня блоков за пару минут работы - это труп.
Можете прогнать тест записи, затем ещё раз тест чтения. Может быть ситуация улучшится, хотя учитывая и так свежую переустановку системы на нём - т.е. интенсивную запись - очень сомневаюсь. И что-то важное хранить на этом диске нельзя.
