Иван Филатов: Так я и предлагаю у хостера узнать какая у них система и дают ли они доступ к ней. Легенда для хостера - возможность создания резервных копий установленной ОС.
Иван Филатов: Вы фактически уже пользуетесь похожим механизмом (виртуализация). В зависимости от системы, есть варианты сделать перенос легко вообще без переустановки (нужно перетащить образ установленной ОС). Как пример, в VmWare такое есть. Не исключено, что в родной виндовозной HyperV тоже есть.
Я видел, что есть доступ только по RDP. Понимаю, почему не просите ничего дополнительно (вероятно, боитесь вообще все потерять, если хостер узнает от подготовке к переезду). Но у Вас ведь все равно есть резервные копии, которые Вы делаете в Windows по каждой из используемых систем. Чего тогда бояться?
Нужно узнавать какая у вас система виртуализации и смотреть что эта система дает для резервного копирования/переноса образов. Найдете подходящее - закажете на время переноса и все. Только туже систему виртуализации нужно будет иметь на новом месте.
Да и средства миграции Windows есть смысл изучить (слышал, что есть, сам от Windows отошел давно).
Во всяком случае, я бы сам делал так. Уровень подготовки у меня сравним с Вашим. Байки по VmWare я слышал от своего админа. Он имел удаленный доступ к системе виртуализации и делал резервные копии образов ОС на свой ПК. Ну а где есть архив, есть и восстановление из него.
Кирилл Фирсов: скорее всего, у вас использована опция
-I
Override the default size of each slab page. Default is 1mb. Default is 1m, minimum is 1k, max is 128m. Adjusting this value changes the item size limit. Beware
that this also increases the number of slabs (use -v to view), and the overal memory usage of memcached
У меня фокус не прошел. Правда, мог и сглупить. При отмене подписки галочка автоматически была установлена на удалении моего домена. Я ее не снимал. После добавить домен уже нельзя.
Пригоден только для мощных маршрутизаторов с доступом к их cron и возможностью запуска curl, wget или аналога. API явно не совместим с тем, что принят на DynDNS. Т.е. зайти в настройки маршрутизатора, выбрать там провайдера DynDNS и забить некий "кастомный" вариант с альтернативой узлу dyndns.org низя.
Наиболее реально применить этот сервис на обычном ПК или сервере (но зачем, у него фиксированный IP).
Похоже, вопрос возник из-за сообщества дистрибутива, а не его самого ... Стоит ли беспокоиться из-за пары сомнительных личностей? Я не знаком с Gentoo (просто считаю, что он мне не по зубам), просто интересно откуда ноги растут у вопроса.
Данил Загорский: "грызите" nokogiri habrahabr.ru/post/110112 .
Сложность зависит от конкретного сайта. Никогда web архив не парсил.
У Вас все равно выбора нет, какая разница ....
FanatPHP: это я видел (сейчас узрел, что примеры по mysqli там есть), уговорить сам MySQL не делать буферизацию это не поможет. Так что вопрос о памяти имеет право на жизнь.
FanatPHP: за инфо спасибо (правда, сходу в mysqi не нашел, есть только в mysql). Тогда свой код в PHP может удвоить или утроить потребность в памяти. Если говорить о MySQL, то он в своей памяти все равно хранит результат и он зависит от количества строк. Так что фокусы в PHP решают не все, нужно понимать что и из какой таблицы берешь ...
Jodes: ответ зависит от блокировок.
Если таблицу не блокировать, то разницы для PHP никакой, что все сразу выбрать, что пачки перебирать.
А вот для СУБД разница есть определенно. Сложность запроса одна и таже, СУБД вынужден делать выборку каждый раз полностью и из нее вычленять диапазон.
Все эти нарезания нужны только если если особый алгоритм (какой - трудно представить, нужно знать задачу), либо идет борьба с блокировками (но там могут быть проблемы, я уже написал о них).
Jodes: человек старается объяснить, что для перекладывания записей из одного места в другое не нужно хранить всю пачку единовременно. Вы же о своем алгоритме пишете так, что не ясно зачем ОБЯЗАТЕЛЬНО так делать. Вот и идет "дискуссия" ни о чем. Пачка нужна, если есть какой то алгоритм помимо перекладывания, требующий рассмотрения нескольких записей и это нельзя сделать в один проход (при том самом пресловутом переборе по одной записи). Это что касается PHP.
А на стороне СУБД болячку не обойти - там будет строиться результирующий набор и сожрет он столько памяти, сколько будет выбрано строк.
На стороне PHP можно только не увеличить вдвое требуемый объем памяти.
Чего тогда спор - вот вопрос ...
FanatPHP: смотря как работать. Если человек написал, что его беспокоит память, значит так оно и есть. А съесть ее можно всегда ... Будут основания для изменения алгоритма - изменит сам.
Я бы был рад увидеть реально хорошего верстальщика. Видел работу только одного, о которой можно говорить как об исключительной. На фоне десятков тех, что просто ее как-то сделали. Если человек достигнет совершенства в этом деле, цены ему не будет.
Jodes: имел печальный опыт, мало памяти - увеличивайте память. В противном случае будете иметь проблемы с изменениями данных между запросами пачек на посещаемом сайте. При добавлении новых строк будете считывать одни и теже в соседних пачках. При удалении - некоторые вообще не увидите.
Кстати, на какой платформе эта версия у Вас? Мне вчера или позавчера обновили Skype на Windows 8.1. До этого момента удивлялся что там у людей за проблемы ... Теперь сам знаю.
